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Présentation 


Ce rapport intermédiaire rend compte des activités du groupe d’Intelligence 
Artificielle de l’Université Paris-8-Vincennes rattaché au LA 248 dans le 
cadre de L’ATP 4273. Ces activités sont essentiellement cons acrées aux 
implémentations et améliorations ainsi qu'à la diffusion du langage et 
à ses applications principales parmi lesquelles La compréhension 
automatique de programmes et l'aide à la programmation. 


En 1980, une nouvelle application a été développée par le groupe: les 
éditeurs vidéo couplés à MISP, et en particulier les systèmes de fenétrage 
dynamiques et interactifs. Ces applications sont en cours de développement 
pour les systèmes 8 et 11, et un nouvel éditeur vidéo interactif 
pleine page: TIV, a été implémenté sur une large variété d'ordinateurs de 
type PDP-11 (11/40, 11/34, 11/55, LSI-11, Plessey, Heathkit) et a été rendu 
disponible pour les terminaux VI50, VTS52, Perkin Elmer 550, VT100, H83, 
Televideo Inc, VT11 graphique. Cet éditeur est en cours de diffusion et 
est utilisé à l'Université Paris-8, à L'IRCAM, à l’Université de Stanford, 


* 


à l'université Paris-Sud ainsi qu'à l’Université de Poitiers. 


Le présent rapport intermédiaire présente les travaux du groupe dans ces 
domaines, et inclut pour chacun d'entre eux une large bibliographie. 
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Le modèle [VLISP : 


description, inplémentation 


et Svaluatien 


Jérôme CHAILLOUX 
Octobre 1980 


Notre étude présente la réalisation de rois systèmes (dialecte du 
Langage LISP) développés a l'université de Paris 8 - Vincennes. Ces 
systèmes ont été réalisés i 

- sur micro- processeur à mots de 8 bits (Inte18080/Zilog80) 

- sur mini-ordinateur à mots de 16 bits (PDP11) 

- sur gros ordinateur à mots de 36 bits (PDP10) 


De ces réalisations est extrait un modèle d'implémeniation. 


Cette étude propose des solutions aux problèmes de construction et 
d’évaluation de tels systèmes. Ces problèmes sont : 


1) La description exhaustive des imp Lémentat ions. 
Nous proposons une description fondée sur la machine référentieile VCMC2. 


2) La représentation ,adéquate des objets et des fonctions [VLISPI. 
Nous avons associé des propriétés naturelles aux objets dés leur création 
et nous avons établi une typologie fonctionnelle de ces objets. 


3) L'efficacité de l'interpréte (en place, en temps d'exécution et en 
compréhension). Notre interprète effectue, pour ses besoins propres, une 
allocation optimale de la mémoire (allocation mesurée en terme d'appels 
du module CONS). L'accés direct (ne nécessitant qu'un accès mémoire) aux 
valeurs des objets de type variable et fonction, et la classification des 
fonctions par types permettent un lancement immédiat de toutes les 
fonctions. La transparence de nos méthodes de description est une 
conséquence naturelle des deux choix précédents. 


4) Le pouvoir des structures de contrôle, 
Notre modèle d'implémentation généralise les te nee de contrôle de 
VLISF] SELF et ESCAPE en intégrant les nouvelles constructions EXIT, WHERE 
et LETF et en unif liant totalement Leur description et Leur 
implémentation. 


9) La souplesse d'utilisation du système. 
Nous introduisons le nouveau concept de CHRONOLOGIE qui permet de créer 
dynamiquement de nouveaux évaluateurs, permettant Les traces 
méta-circulaires. | 


Une incarnation de notre modèle est donnée dans  [CHAILLOUX 801, sous la 


forme de la réalisation d'un système pour la machine référentielle 
VCMC2. 
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1.0 HISTORIQUE CRITIQUE DE L'IMPLEMENTATION DE LISP. 


A PS 


Le langage LISP [BERKELEY 74, WEISSMAN 67, ALLEN 781 est aujourd'hui le 
langage le plus utilisé dans les domaines de L’ Intelligence Artificieile 
[WINSTON 771 et de la théorie de la programmation INIVAT 791. La 
particularité majeure de LISP est d’avoir pu évoluer de façon naturelle 
depuis sa naissance en 1960 IMcCARTHY 60a, 60b]l, à mesure gu’ apparaissaient 
de nouveaux besoins. l'échec patent des rares tentatives de 
standardisations {Note 1} a d'une part permis sa survie et d'autre part 
conduit à une amélioration constante du langage tant en efficacité à 
L' interprétation qu'en pouvoir de ses concepts. 


IL en résuite aujourd'hui une floraison d'implémentations, bien loin du 
premier LISP 1 [McCARTHY 60al, ayant chacune des spécifications 
particulières en fonction de leur utilisation et du moment de leur création. 


On distingue ainsi 4 grandes familles d'implémentations : 


1) La Lignée LISP 1.5 IMcCARTHY 621, Descendante directe de LISP 1 qui 
était un système interactif (avec le "FLEXONRITER system"), elle a donné 
le LISP 1.6 [QUAM 721 très proche de LISP 1.5, mais ayant abandonné la 
Liaison par A-liste, décision dont les conséquences ont été monumentales. 
Par la suite, l'importance capitale de l'intégration des instruments ce 
mise au point devint de plus en plus évidente, et LISP 1.8 fut augmenté 
d'un éditeur et d'aides à la mise au point pour donner te U.C.I. LISP 
[BOBROW 73al. 


2) Les systèmes INTERLISP (anciennement BBN LISP) [TEITELMAN 751 orientés 
sur une utilisation exclusivement interactive, et qui ont donnés 
naissance à des sous-systèmes tels que CLISP [TEITELMAN 731 ou DLISP 
[TEITELMAN 771 qui font une utilisation intensive de périphériques 
interactifs tels les écrans à haute résolution. 


3) MACLISP IMOON 74, LAUBSCH 761 au M.I.T. dont le développement s’est 
réalisé en symbiose avec celui du systéme MACSYMA [MACSYMA 751 et qui a 
inspiré la conception de la machine LISP du M. T. T. INEINREB 791. 


4) Enfin les systèmes  VLISP [GREUSSAY 76a, CHAILLOUX 78a,  CHAILLOUX 801 
développés en France à l’Université de Paris 8 - Vincennes, implantés sur 
Les 3 catégories de systèmes matériels (gros, mini et micro) et qui sont 


dotés des structures de contrôle les plus puissantes. 


Le point commun de ces familles d’implémentations est d’avoir toutes une 
réalisation sur l'ordinateur de référence PDP-10 [DEC 78al, qui est la 
machine la plus utilisée dans le cadre des recherches en Intelligence 
Artificielle. Pour cette raison les performances de ces différentes 
réalisations sont aisément mesurables. 


En plus du PDP-10, ces systèmes LISP n'ont été implantés que sur un nombre 
restreint d'autres matériels en général de taille tres importante tels L’ IBM 
série 360/370 [BOLCE 68, HAFNER 741, L’UNIVAC 1100 ou L*IRIS-50 pour lequel 
on dénombre 3 réalisations en France, le TLISP à l’Université Paul Sabatier 
de TOULOUSE IDURIEUX 781, le RLISP au laboratoire IMAG de GRENOBLE [LUX 78] 


i LS 


{Note 1} ces standards sont aussi prématurés qu'arbitraires. Prématurés car 
ils tombent en désuétude aussitôt créés (voir le standard de [HEARN 69] puis 
[MARTI 79]) et ne tiennent pas compte de l'évolution du langage, arbitraires 
car ils sont essentiellement définis pour satisfaire un programme 
particulier (REDUCE 2 dans le cas de HEARN [HEARN 73, 74]). 
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et SIRLISP à L’E.N.S.T de Paris [COILLAND 791. 


LISP 1.5 et LISP 1.6, hormis des réalisations-jouets à fins pédagogiques, 
sont à présent tombés en désuétude. 


MACLISP et INTERLISP, trop dépendant de la machine PDP10 (et même du système 
d'exploitation utilisé respectivement ITS et TENEO n'ont pu être 
transportés dans leur intégralité sur d'autres machines {Note 1}. 


Seul, VLISP, (du fait probablement de sa conception en Europe et de ta 
diversité des ordinateurs qui y sont disponibles) a pu (ou a dû) être 
réalisé sur un grand nombre de machines très variées telles que CAESIO 
[GREUSSAY 721, CABS00 [WERTZ 741, 11600 IGREUSSAY 751, FDP10 
[CHATLLOUX 78cl, SOLARIG [GREUSSAY 78b], 8080 et Z80 ICHAILLOUX /9al et 
PDP11 [GREUSSAY 79bl. 


La diversité de toutes ces réalisations a entrainé la naissance d’histoires 
(et d’historiens) de LISP, apportant de précieuses informations sur 
L'évolution naturelle des langages de programmation {Note 27 [McCARTHY 781 , 
[WHITE 781, [STOYAN 78a,78bl. 


Les recherches actuelles de construction des systèmes LISP s'élaborent pour 
l'essentiel selon les 4 axes suivants : 


- implémentation sur des ordinateurs universels classiques tel Le VAX-11 
[DEC 78el ou Le S-1 [HAILPERN 791. 


- implémentation Sur des ordinateurs spécialisés, ^ voire des 
micro-ordinateurs, à ressources limitées [CHAILLOUX 78a, TAFT 791. 


- réalisation de machines spécialisées [GREENBLATT 74, KNIGHT 74, 
SHIMADA 76, LISPMACHINE 77, LECOUFFE 77, TAKI 79, WEINREB 791. 


- apparition d'unités centrales, en technologie  V.L.S.I. [MEAD 801, 
capables d'interpréter directement LISP à une translation près du langage 
source en sa représentation arborescente, dont le répertoire des sommets 
constitue un jeu d'instructions d'interprétation directe de LISP (les 
CHIP-LISP) [STEELE 79, HOLLOWAY 801. 


{Note 1} En date de Septembre 1978, MACLISP ne -tournait encore qu'avec 
beaucoup de difficultés, en ce qui concernait ses aspects-systeme évolués, 
au laboratoire d'Intelligence Artificielle de Stanford, sous système WAITS 
[GREUSSAY 78a]. 


* 


(Note 2] Par opposition aux cas de langages à génération spontanée ou à 
comités [HORNING 79], à définition discrétionnaire. 
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2.0 COMMENT DECRIRE LES IMPLEMENTATIONS la machine UCHUS. 


Des son apparition LISP a été exposé méta-circulairement ¿Note 1} afin 2 
décrire ses propres implémentations. 

Cette utilisation de LISP, trés commode, ne satisfaisait pas les 
imp Lementeurs experts, qui n'avaient à leur disposition que ces descriptions 
méta-circulaires accompagnées, dans le meilleur des cas, du texte d'une 
implémentation particulière. Tous les problemes réels d' implémentation en 
machine étaient soit totalement ignorés (dans le cas où LISP était utilisé à 
sa propre descr iption) soit entièrement orientés vers une machine 
particulière. 


Pour illustrer cette situation, nous utiliserons dans cette section, une 
succession progressive de descriptions du module classique EVLIS : nous 
partirons de sa description méta-circulaire en LISP, nous la qualifierons 
sur des machines particulières, enfin nous en donnerons La DESI Li dans 
notre modèle de référence. 2. oo... oe a 


Voici la description de la fonction EVLIS, en LISP classique, telle quelle 
est donnée dans les manuels de référence : 


LISP cizssiaue 


(DE EULIS CL) 
(COND 
CCNULL L) NIL) 
(T (CONS CEURL (CAR L)) CEULIS (CIR L))3)3))) 


Une telle description purement méta-circulaire était déjà remise en question 
par John McCARTHY, Le créateur du langage : il introduisit deux langages 
LISP, un Langage algorithmique (le Méta-langage) qui utilisait des 
M-expressions et un langage de programmation (le LISP tel qu'on le parie 
encore) qui mettait en jeu les S-expressions  [McCARTHY 621. Ce double 
Langage permettait de distinguer les données décrites en S-expression des 
programmes décrits sous forme de M-expressions [PERROT 791. 


(Note 1} LISP est spécifiable par un interprète dit méta-circulaire : un 
tel interprète, écrit en (WLISP, ramasse en une seule description la 
spécification du langage et celle de l'interprète lui-même (voir Ta 
ey de T'évaluateur  WLISP-I0 en VLISPI-10 donné dans [CHAILLOUX 78c] 
page 20). 
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La traduction du langage algorithmique vers le 
automatiquement {Note 1}. 
le langage de programmation a survécu. 


devait s'effectuer 


Langage de programmation LISP 
on sait aujourd'hui que seul 


Voici donc La description de la fonction EVLIS en utilisant la notation sous 


forme de M-expressions 


M-expressions 
evlisLl32Enul LELISNIL; TocenstevalEcartu11;evtistedrE 11111 


Si on considère qu'une implémentation particulière constitue une description 
de référence on se heurte aux deux difficultés que sont : 


1) l’opacité inhérente à 


source 


la méconnaissance 


préliminaire de l'ordinateur 


2) la non-généralité chronique de ce type de description. 


Voici donc cette méme fonction telle 


machine du PDP10 I[CHAILLOUX 78c] : 


qu’elle 


est codée dans le langage 


Q1 EULIS: 


02 JUMPE 
03 HRRZ 
04 PUSH 
05 PUSH) 
06 HLRZ 
07 EXCH 
08 EXCH 
09 POP 
10 CAMGE 
11 JRST 
12 PUSH 
13 PUSH 
14 PUSH 
1 MOVE 1 
16 EULIS1: 
17 HRRZ 
18 MOVEM 
19 PUSHJ 
20 HLRZ 


(Note 1] c'est 
perforatrice de 
M-expressions. 
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l'absence 


Lengsge machine PDP-10 


81,UPDPJ 

A2, MEMCAT) 
P, A2 

P, EVALCA 

A1, MEMCA1) 
A1, MEM CPREE) 
FREE, A1 


P, A2 
AT, (A2) 


A2,MEMCAT) 


P, EVALCA 
A1, MEMCA1) 


des 


Su we Ut wp aus 


caractères spéciaux [, ], et » 
cartes IBM026 qui a empéché l'utilisation systématique des 


pas d'argument 


Re e (CDR AT) 


qui est sauvé 
évalue la ière val. 
A1 e (CONS R1) 


récupere le reste 
au moins e ? 

non : fini 

sauve le ter doublet 
sauve le dernier 
sauve le reste 

Al e les arguments 


Re + (COR A1) 
dans le sommet de la pile 
évalue l'argument suivent 
A1 + (CONS R1) 


sur la 


Page 6 | i | Le mocate [VLISP 


| 21 ACH AT, MEM(FREE) | 
| £2 ACH FREE, f11 | 
| 23 MOVE A2,-1(P) ; R2 «€ le dernier double | 
| 24 HARM AT, MEMNCRE) ; (RPLECO R2 A1) | 
| 23 MDUEM A1,-1(P) ; Sauva le dernier doublet | 
| 25 {OVE AT, CP) ; Ail ¢ le reste | 
| 27 CAML AT, BLIST ; il reste des élénents ? | 
| 28 JRST EULIS1 ; Cui. | 
| 29 cus P,[3,,31 ; nen : nettoie la pile. | 
| 39 MOVE A1, 1P) ; Al < ter doublet | 
| 31 UFOPJ: | 
| 22 POPJ P, ; et voila. | 
| 


Le point 1) est illustré ici par l'instruction MOVEI, utilisée 
15, qui emploie classiquement la propriété d’adressage suivante 


Ligne 


ee fo^ 
Lond 
y 


immédiat + indexé = direct 


et permet un gain substanciel de temps : 


Tengs d'exécution des instructions 


MOVE | R1,R2 1.14 micro-sec 
MOUEI AT, CAB) 0.62 micro-sec 


sur l’unité centrale PDP 10 KI [DEC 78al. 


On notera également la confusion conceptuelle introduite par l’utilisation 
du pointeur de pile P comme registre d’index, pointeur qui ira même (voir la 
Ligne 30) jusqu’à être employé à l'extérieur de la zone pile. 


La non-généralisation de cette description est malheureusement une 
conséquence de l’utilisation raisonnablement experte d’une machine 
particulière. 


Nous devons aller au delà de ces 3 représentations pour aborder, décrire 
correctement, résoudre enfin les véritables problèmes d’ implémentation en 
machine : 


- la représentation en LISP classique montre assez bien l'intention de la 
fonction mais ignore complétement les problèmes d'allocation des 
ressources, souvent limitées, ainsi que la gestion de la récursion. 


- la représentation en M-expressions tout en évoquant approximativement une 
notation algébrique présente les mémes inconvénients que la représentation 
en LISP et introduit un niveau supplémentaire de traduction. 


- la représentation en langage machine PDP10 fait surgir de nouveaux 
problèmes locaux tels que l'accès aux demi-mots de la machine voire 
l’utilisation du pointeur de pile comme registre d'index. La description 
en langage machine est alors supplantée par l'expérience nécessaire à la 
mise en jeu correcte d'adressages et de jeux d'instructions particuliers. 
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Nous proposons donc de représenter l’ implémentation au moyen de programmes 
d'une machine de référence, la machine VCMC2, descendante directe de ia 
machine VCMCl [CHAILLOUX 78bl, et indépendante des représentations internes 
des objets eux-mêmes. C'est de cette description que naissent naturellement 
les incarnations opérationnelles particulières de sur les ordinateurs 
les plus diversifiés. Cette machine, décrite dans [CHAILLOUX 801, est 
simulée en VEISP+-10 sur ordinateur PDP-10. 


La description de ISF très concise, qui en découle dégage L 
caractéristiques fondamentales de L’ implémentation de modules tels que EYL 
en machine, i.e. : 


1) les actions de base (test par rapport à NIL, CDR, CONS ... ) 


2) la gestion de la récursion par utilisation d'une pile et d’un 
accumulateur. 


3) le mécanisme du sauvetage et de la restauration du reste de la liste et 
du résultat intermédiaire au travers de la pile. 


4) 1? internalisation totale des fonctions interfaces : entrées/sorties et 


traces (ce que ne pouvait pas faire la notation FILTRE de [GREUSSAY 


Voici donc la description, en VCMC2, de L’implémentation en machine de la 
fonction EVLIS : 


La fonction EULIS décrite en VCMCe 
EULIS:  TNIL Fil, , [RETURN] 
COR 


A1, TST, LCRLL (EUCAR) 1 
ATDPST A1, , [CALL (EULIS3 1 
CONS TST,R1, [RETURN] 


Cette représentation générale atteint le degré de précision suffisant pour : 


1) appréhender la véritable structure en actions de base de lL’ implémentation 
(ce que ne pouvait pas faire la description d' INTERLISP {Note 1] 


{Note 1] la notation utilisée dans la description de [MOORE 76] ressemble à 
la notation sous forme de M-expressions et ne rend pas compte de 1a gestion 
de la récursion et des résultats intermédiaires. Sachant que EULIS est le 
version SUBR du module LIST (de type FSUBR) [MOORE 76 pp. 11] ne peut 
décrire cette dernière qu'elliptiquement par le dispositif typographique des 
points de suspension : 


LIST[x1;x2;...xk] 
Return CONS[x1;CONS[x2; .. .CONS[xk;NIL]. . .]] 
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2) expliciter totalement la gestion de la pile de récursion en unifiant 


sm coli, 
to 
l’adressage la mise en jeu des accumulateurs et du cache de pile. 


em, 
Ge 


3) indiquer la circulation dans la pile des états d'évaluation 
intermédiaires du contenu initial du registre Al 
4) préciser enfin la structure de contrôle par attachement à 


chanus 
instruction d’une continuation complexe. 
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3.0 EFFICACITÉ ET PUISSANCE DE L'INTERFRETATION. 


Du fait de sa représentation des objets et des fonctions, notre modèle 
permet de réduire considérablement le temps d'interprétation et de disposer 
d’un grand nombre de structures nouvelles, qui facilitent l'écriture des 
programmes, en améliorent la lisibilité et en diminuent sensiblement la 
taille. 


Voici la définition de La fonction de FIBONACCI utilisée pour des 
comparaisons de vitesse sur plusieurs interprètes LISP fonctionnant sur 


PDP10 : 


(DE FIB in) 
(COND 
CCZERDP n) 1) 
CEQ n 1) 1) 


CT (PLUS (FIB (SUB | ni (FIB (DIFFER n 2)))))) 
(FIB 20) EP 10225 


Voici les temps relevés sur MACLISP, INTERLISP, MISP-10 et VWLISP-11 {Note 1} 
pour le calcul de l’appel (FIB €0) : 


[Temps en secondes] 


MACLISP  INTERLISP X WLISP-10  [VLISP-11 
48.65 105.78 13.34 35.2 


La rapidité remarquable de l'interprétation de notre modèle est die : 


1) à l’utilisation intensive des propriétés naturelles des atomes et 
principalement du type associé à chaque fonction. Le type d'une fonction 
LISP est déterminé par le langage dans lequel elle est écrite, le mode de 
passage de ses arguments (les arguments sont ou ne sont pas évalués) 
ainsi que le nombre de ses arguments. Cette typologie est abondamment 
décrite dans [CHAILLOUX 80 chapitre 4]. Ce type est directement 
accessible, ce qui permet de réaliser en même temps et le test du type et 
l’appel de la routine associée, au moyen d'un seul branchement indirect 
indexé. En terme de syntaxe, utilise donc l'appel per nom des 


{Note 1} MACLISP utilise dans le cadre de ce test une unité centrale  PDP10 
KA-10 et des mémoires à 1.8 micro-secondes [WHITE 76], INTERLISP une unité 
centrale PDP10 KA-10 et des mémoires à 1.0 micro-secondes, NLISP|-10 une unité 
centrale PDPiU KI-10 et des mémoires à 1.0 micro-secondes.  [VLISP|-17 n'a à se 
disposition qu'une micro-unité centrale LSI 11/02. 
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fonctions. 


2) au fait que l” interprete ne réalise plus aucun CONS pour ses besoins 
propres. L'utilisation exclusive d’une pile commune de données et de 
contróle évite de créer des structures intermédiaires (sous forme cs 
cellules de Liste) durant le processus d'évaluation. Le nombre ae 
récupérations de la mémoire dynamique se trouve ainsi réduit aux seuls 
besoins de l'utilisateur ¿Note 1}. 


3) à l'interprétation itérative des fonctions récursives de type NPR et CPR 
[GREUSSAY 76cl. 


4) à l’utilisation des structures de contrôle de MSA qui permettent une 
écriture plus concise et une interprétation plus rapide. En 
particulier : 


- l'opérateur point-fixe du A-calcul [ROBINET 781, représenté par la 
fonction SELF de [GREUSSAY 77] 


FIBONACCI se reécrit alors commodément : 


(DE 7 (n) 


(ZEROP n) 1 
CIF CEQ n 13 1 
(PLUS (SELF (SUB1 n?) 
(SELF (DIFFER n 23333) 


- les fonctions d’échappement ESCAPE. Introduites par  IGHEUSSAY 76b], 
elles permettent d'associer dynamiquement des fonctions d'échappement à 
des atomes, réalisant ainsi des sorties non-locales. 


5) enfin à de nouvelles structures de contrôle. Ces nouvelles structures de 
contrôle vont pouvoir réaliser : 


- la description de fonctions anonymes (i.e. qui ne sont pas associées à 
des noms) en utilisant la forme INTERNAL. 


- les sorties locales à une fonction en utilisant la fonction EXIT. 


- la redéfinition dynamique de fonctions de n'importe quel type en 
utilisant la primitive WHERE. 


- la définition d'une nouvelle classe de fonctions, les variables 
fonctions, apportant une solution nouvelle au problème des variables 
internes. 


D SAR MM 


{Note 1} La gestion de la mémoire en LISP est automatique et dynamique ce 
gui assure une utilisation optimum de la place mémoire mais oblige à 
construire des modules d'accès et d'allocation (le module CONS) spécialisés 
ainsi qu'un récupérateur de mémoire, dispositif qui ralentit l'interprète. 
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3.1 Descriotion de fonctions anonvmes 


Notre modèle permet de décrire des fonctions anonymes (non associées à des 
symboles atomiques) de n'importe quel type au moyen d'une des deux fornes 
INTERNAL suivantes : 


(INTERNGL type edresse-mémnolre) 


CINTERNAL type fonction) 


La première forme permet de décrire des fonctions écrites en langage 
machine, et la seconde des fonctions écrites en WLISP). 


Ces deux nouvelles formes généralisent l'ancienne utilisation de la forme 
LAMBDA (qui a été gardée par souci de compatibilité et de simplification de 
l'écriture des EXPR anonymes) pour tous les types de fonctions et permettent 
ainsi de Limiter l’utilisation des noms associés aux fonctions. 


Cette Limitation des noms réduit d'autant plus l'espace mémoire nécessaire 
au stockage des symboles atomiques et accroit la Lisibilité du programme qui 
ne contient plus que les noms indispensables. 


3.2 Sorties locales 


La forme EXIT permet de sortir de la dernière fonction invoquée de type 
EXPR, FEXPR ou MACRO. La valeur retournée est évaluée dans l'environnement 
précédant exactement le retour de cette fonction donc évaluée en position 
terminale. Cette propriété est utilisée pour forcer un traitement de 
récursion terminale fNote 17 ce qui n'était pas le cas des fonctions RETURN 
des anciennes formes PROG {Note 2]. 


Voici la méta-description de la fonction MEMBER qui utilise la structure de 
contrôle itérative WHILE. 


ae e i a a a E E a om PP 


(Note 1} Ces appels récursifs terminaux sont  interprétés d'une manière 
itérative beaucoup plus efficiente. 


{Note 2} La Forme PROG a été abandonnée dans notre modèle (ainsi que ses 
fonctions associées GO, GOTO et RETURN) car Tes nouvelles fonctions de 
sorties locales et non-locales sont à la fois plus rapides (en effet le 
balayage préliminaire de tous les corps de PROG pour construire la table des 
étiquettes a disparu) et plus générales (avec la possibilité de retourner 
directement d'un nombre quelconque d'appels). 
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(DE MEMBER (a D 
CHILE L 
CIF CESURL CCAR D a) 
(EXIT D 
(NEXTL 022) 


L'appel de ta fonction EXIT permet une sortie extraordinaire du WHILE. 


3.3 Définitions dynamiques de fonctions 
La forme WHERE permet de définir dynamiquement de nouvelles fonctions et de 
rendre fluides {Note 1j les fonctions elles-même. 


Voici la syntaxe de cette nouvelle forme : 


| (WHERE («nom» <fval>) <s1> ... «sN») 


Le premier argument du WHERE est une définition temporaire d’une fonction 
<fval> associée au nom <nom>. Le reste des arguments du WHERE i.e. 
<si> ... <sN> est un corps dans lequel la définition précédente est active. 
Au sortir du WHERE, ta définition associée au nom «nom» disparait et sa 
définition antérieure (s’il en possédait une) est restaurée. 


Voici La fonction de traçage d'une courbe Dragon [GARDNER 67,  SCHOETIL 751 
en LOGO-LISP [WERTZ 79] dans laquelle la fonction tourne est redéfinie 
dynamiquement. 

Les fonctions <avance>, <droite> et <gauche> sont des primitives LOGO : 


(DE tourne O («droite» 95)) 


(DE dragon tn D 
(IF (ZEROP n) 
(<avance> |) 


(WHERE Ctourne 'C(O) (<cauche> 90))) 
(dragon (SUBI m 13) 

(tourne) 

(WHERE (tourne '(0 (<droite> 98002) 
(dragon (SUB1 n) 1133) 


— 5 iR ER ERR e E E P —— 


(Note 1} Une variable fluide est une variable libre liée dynamiquement. 
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3.4 Les variables foncttons 


Notre modèle propose une solution au problème de l’accès aux variables 
internes Note i? de L’ interprète. En effet, un choix crucial 
d'implémentation se pose. 

Il n'est que trop tentant d'utiliser des variables VLISP pour accèder à ces 
variables internes. Appelons OBASE la variable interne qui contient à tout 
moment La base de numération des nombres en sortie. Une affectation 
incorrecte de cette variable (par exemple avec une valeur négative), 
détruirait toute possibilité future d'impression de nombres. 

Une deuxième stratégie consiste à utiliser une fonction associée à chaque 
variable interne. Cette fonction va contrôler La validité des valeurs 
affectées à la variable. C’est ce qu'on entend par. var iabilisation ou 
fonctionnalisation de l'accès. 


oo ES 


C'est cette dernière stratégie qui a été adoptée dans notre modèie. De plus 
celui-ci propose une nouvelle classe de fonctions, les variables fonctions, 
qui permettent dans une stratégie de fonctionnalisation des variables 
internes de lier dynamiquement les valeurs de ces variables internes, 
retrouvant ainsi toutes les propriétés des variables. 

En lecture ces variables fonctions n'ont pas d'argument et en écriture elles 
possèdent un argument (évalué) qui est la nouvelle valeur de la variable 
fonction. | | 


| ` tvarisble-fonct ion) lecture 
| (varieble-fonction valeur) écriture 


La nouvelle structure LETF réalise la Liaison dynamique des variables 
fonctions. Elle possède une syntaxe identique à la macro LET : 


(LETF (variable-fonction valeur) corps-du-LETF) 


La 


I I 2 


{Note 1} rappelons que ces variables internes sont Îles mots mémoires de 
travail de l'interprète et qu'il est souhaitabie que l'utilisateur ait accès 
à certaines de ces variables pour faciliter l'utilisation du système et en 
augmenter la puissance. 
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y 


Cette forme est exécutée en 4 temps : 


1) appel de la variable fonction en lecture (sans argument). 


retournée est conservée. 


2) appel en écriture de la variable fonction avec  l'argument 


LETF. 


La valeur 


transmis au 


3) exécution en séquence du corps du LETF qui calcule ia valeur retournée 


par la forme LETA. 


4) re-appel en écriture de La variable fonction avec en 


ancienne valeur conservée en 1). 


Ce type de Liaison (de même que celle des variables) 


CMA R= 


argument son 


est réalisée 


2 
automatiquement et en pa rticulier le point 4) est effectuée en cas de sortie 
1 


extraordinaire par un Yl ou un ESCAFE enveloppant. 


L'utilisation de ces variables fonctions permet donc d’associer à des 
variables des fonctions qui réalisent des contrôles d’accès dynamiques tant 


en lecture qu’en écriture. 


Voici un exemple d'utilisation de la variable fonction DBASE 


E qui contrôle la 


base de conversion des nombres en sortie. La fonction PRINT-base-x imprime 
son 2ème argument n dans ia base de numération x fournie en ler argument : 


(GERSE) re 10 


(DE FRINT-bese-x (x n) 
(LETF CQBASE x) 
(PRINT nd) 


(PRINT-bass-x 16 1000) 
(GBASE) cw 10 
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4.0 LA SOUFLESSE D'UTILISATION. 


Un certain type de programmation-systéme consiste à implanter, valider (ou 
invalider), mesurer, modéliser de nouveaux types d'architectures logicielles 
ou matérielles (par simulateur), à la Limite de l'élaboration de modèles en 
Intelligence Artificielle. 

Cette programmation se fera tout naturellement dans les conditions les plus 
interactives et les plus expérimentales possibles, et nécessitera des outils 
permettant la réalisation la plus rapide du modèle à valider. Cette 
activité demande donc un langage puissant, très facilement et très 
rapidement mis en oeuvre, car les temps de vie des différents modèles sont 
extrêmement brefs et soumis à des modifications incessantes. 


Ainsi notre système ne mésestime pas l'expertise de ses utilisateurs. IL 
s'agit d'un systéme utilisable et utilisé, illustrant la nécessité, parfois 
sous-estimée, de ne pas entraver l'expertise raisonnable de ses utilisateurs 
(par exemple en ne l'encombrant pas de contrôles statiques contraignant à 
une programmation médiocre) mais,.tout au .contraire,.. de leur . fournir le 
maximum de pouvoir et de souplesse expressive. 


L'utilisation réelle d'une tel système nécessite la faculté de contrôler par 
niveau le fonctionnement de L’interpréte, ce qui amène tout naturellement à 
L'idée d'évaluateurs multiples selon les circonstances du calcul. Les 
outils de contrôle de chronologie, traces et erreurs qui vont être décrits 
en sont une illustration. 


4.1 La notion de CHRONOLOGIE 


Notre modèle dispose d'une multitude d'évaluateurs potentiels différenciés 
par un numéro d'ordre de création, un numéro de chronologie. L’accés à 
cette chronologie est réalisée au moyen de la variable fonction CHRONOLOGY. 


Ces évaluateurs peuvent être appelés : 


- par l'utilisateur au moyen de La fonction interprète EVAL dont le deuxième 
argument est le numéro de CHRONOLOGIE que l'on veut voir affecté à cette 
évaluation : 


(EVAL expression chronologie) 


- soit automatiquement par lL’ interprète, il s'agit alors d’ interruptions. 
Ces interruptions sont déclenchées par des événements externes (horloges 
ou périphériques) ou par l’interprète lui-même dans les cas suivants : 

- appel de la boucle principale du système (TOPLEVEL) 
- erreur à l'interprétation (ERROR) 

— trace de l'évaluateur CSTEPEVAL) 

- ligne pleine en sortie (EOL) 

- apparition d'une fin de fichier d'entrée (EOF) 
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Le traitement d'une interruption se fait par  invocation d'une fonction 
propre à chaque type d'interruption, dans un nouvel évaluateur dont ia 
chronologie est la chronologie précédente incrémentée d'une unité, i.e. : 


CEURL ‘fonction essoción 


La valeur retournée par la fonction associée à l’interruption devient la 
valeur de l’ interruption. 


IL existe de plus une fonction de sortie exira-chronologie, La fonction 
EXITCHRENGLOSY qui réalise la sortie de la chronologie courante et retourne 
une valeur au créateur de cette chronologie. Cette fonction possède la méme 
syntaxe que la fonction de sortie locale à une fonction, la fonction EXIT. 


4.2 Les erreurs 


Notre modèle ne provoque pas l'abandon du travail en cas de détection 
d'erreurs. Lorsqu'il se produit des états d'indétermination dans un 
évaluateur, celui-ci va dynamiquement créer un nouvel évaiuateur. Sa ‘tâche 
est de tenter de lever l'indétermination ou tout au moins de retourner une 
valeur à l’évaluateur interrompu. 


Lorsque ces états d'indétermination sont détectés par un interprète (par 
exemple lors d'une consultation d'une variable non définie), une fonction 
spéciale, La fonction ERROR, est automatiquement invoquée avec comme 
arguments les objets indeterminés, dans un évaluateur différent (dont la 
chronologie est égale à la chronologie antérieure incrémentée d’une unité). 
La | valeur ramenée par cette invocation est utilisée pour lever 
L' indétermination de l’interprète interrompu. 


Cette fonction ERROR (comme toutes les fonctions d’interruptions) peut être 
redéfinie en MI) afin d'utiliser des sytèmes complexes de corrections 
automatiques tel que le système PHENARETE de [WERTZ 781, des outils 
sophistiqués d’aides-a-la mise au point tel que le méta-évaluateur CAN de 
[GOOSSENS 77, 791, des analyseurs [WERTZ 77] des traces ou des steppers 
[GREUSSAY 79al 


Voici un exemple de la redéfinition de la fonction ERROR qui permet de 
construire une fonction testant si une forme peut être évaluée sans erreur 
par EVAL. Dans le cas ou EVAL produirait une erreur cette fonction retourne 
la valeur NIL, et dans le cas contraire elle retourne la valeur de 
L'évaluation. Cette dernière valeur est incluse en premier élément d’une 
liste pour pouvoir distinguer la valeur NIL correspondant à une évaluation 
de cette méme valeur indiquant une erreur à l'évaluation. 
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(DE EVAL-teste-si-erreur (formo) 
(HERZ (ERROR 'CO (Corrour)23) 


(ESCÁSE erreur 
LCEURL forne)1))) 


4.3 Les traces 


Une des facilités majeures de notre modèle est d'avoir un mécanisme interne 
d'observation sélective de l’évaluateur lui-même en fonctionnement. Ce 
mécanisme permet d’appeler la fonction STEPEVAL (qui peut être bien entendu 
redéfinie en MIP) avec comme argument la forme qui doit être évaluée, à 


chague appel interne de l'évaluateur. 


Ce mode trace est activé en donnant une valeur non-NIL au 3ème argument de 
la fonction interprète EVAL : 


CEVAL expression chronologie trace) 


Voici comment réaliser une trace de tous les appels de EVAL. 


(DE TRACEVAL Cexp) 
(WHERE BEEN 
CSTEPEURL (forme) 
(PRINT '— forme) | 
(SETO IT (EVAL forme (SUB1 CCHRONOLOGY)) T)) 
(PRINT 'e 1) 
CEVAL * (STEPEURL exp) (ADDI C(CHRONOLOGY))))) 


; Fonction de test : dernier élément de l; 


(DE FCO (1) 
CIF CNULL (COR 0) CCAR O (SELF (CDR D))) 


; Appel de la trace ; 

(TRACEURL * (FOO ' (A B))) 

— (FOO 'CA B) 

=> (RB) ; 

— (AB) 

— CIF (NULL (COR 0) CCAR OD (SELF (CDR 0») 
— 

—À 

— 


(NULL (CDR 00) 
per $ 
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<< 

¿E 

— Hi 
— (SELF (CUR 0D) 
— nd 13 


«— fn B) 
€- (B) 


— CIF (RULL €COR 03) (CER OU (SELF (CCR 02) 


— (NULL COCOA 12) 
— {COR UD 

— 1 

<— tB) 

— NIL 

— 1 

— (DAR 0 

— i 


Une des difficultés classiques de la réalisation du mécanisme de trace est 
posée par l'interférence entre la fonction traçante et la fonction tracée en 
particulier en cas d'utilisation des constructions SELF et EXIT : en effet 
dans la llème ligne de trace l'appel (SELF (CUR D) doit utiliser la 
fonction tracée (i.e. La fonction FOD) et non pas la dernière fonction 
appelée (i.e. La fonction STEPEURL elle-même). De méme l'évaluation d'une 
forme EXIT peut se rapporter soit au programme traçant soit au programme 
tracé. Pour lever toute ambiguité à l'évaluation des formes SELF et EXIT, 
notre modèle utilise la dernière fonction appelée dans la chronologie 
courante. La fonction traçante et la fonction tracée sont évaluées dans des 
chronologies différentes, ce mécanisme permettant également de réaliser des 
traces méta-circulaires {Note 1}. 


Bien entendu des traces plus élaborées (comprenant des renfoncements 
correspondants aux niveaux d'imbrications des appels ou des numérotations de 
Lignes par niveau et des possibilitées d'exécution incrémentales) peuvent 
étre construites. 


Le fait de pouvoir récupérer TOUS les appels internes de l'évaluateur 
permet, outre les traces, une modification complète de celui-ci. 


{Note 1} KNUTH [KNUTH 69] propose page 211 l'exercice suivant : 

"6. [40] Design a trace routine which is capable of tracing itself, in the 
sense of exercice 4; 7.e., it should print out the steps of its own program 
at siower speed, and that program will be tracing  itseif at still siower 
speed, ad infinitum until memory capacity is exceeded." 

Notre mécanisme de trace permet de ne tracer qu'un seul niveau de la 
fonction de trace. 
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Voici en exemple la fonction EVAL-NiL-si-UNDEF qui se comporte comme la 
fonction interprete standard EVAL mais qui ne provoque pas d'erreur à 
L'évaluation d'une variable indSfinie, se contentant uniquement de donner la 
valeur NIL à la variable et d’imprimer un message d'avertissement : 


(DE EUR 


(Coro) 
CIF CCR (LISTA forme) CNUME? forme) (BOURDE forme)) 
CEURL ferme © T) 
("RINT “Je denne la valeur NIL à :" forma) 
CSET forma MIL333) | 
(STEFEVAL expressiom)) 


Voici quelques utilisations de cette fonction en supposant 


que les variables VARFOO1, VARFOO2 et VARFOO3 sont indéfinies 


? (EVAL-NIL-si-UNDEF ? USRF001) 
Ja donne la valeur NIL à : VRSFO01 
E^ NIL 


? C(EVAL-NIL-si-UNGEF P'e USRECO2 'B USRFDD21) 
Je conne la valeur NIL à : USRFODS 
Ja donne la valeur MIL à VARFCOS 

rm CA NIL B Nil) 


On notera dans cette fonction la redéfinition dynamique de ta fonction 
STEPEVAL, qui permet de n'effectuer le test de variable indéfinie que dans 
la portée dynamique de la fonction EVAL-NIL-si-UNDEF., 
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Une des caractéristiques les plus importantes de notre modèle est d’être 
très rapidement et très facilement implémenté sur les matériels actuels. 
Trois réalisations récentes montrent la diversité des machines pouvant 
recevoir ce systéme : 


1) le système MISP-10 ICHAILLOUX 78cl, est réalisé sur l'ordinateur 
PDP Ki 10 de Digital Equipment Corporation IDEC 78al, sous moniteur 
TOPS10 6.03 [DEC 78b], SAIL [HARVEY 74, FROST 75] et IRCAM [FROST 771. 
C'est le plus rapide et le plus puissant système existent. Il est 
disponible dans les centres suivants :  l'I.R.C. A.M. et le C.I.T.I.2 en 
France, et EDIMBOURG, TURIN et STANFORD SAIL à l'étranger. 


2) le système [VLISP-11 [GREUSSAY 79bl, est réalisé sur l'ordinateur PDP 11 
. également de Digital Equipment Corporation [DEC 751 sous système RT11-Y03 
[DEC 78c1. Ce système fonctionne actuellement sur les processeurs PDP11 


et sur les micro-processeurs LSI11 [DEC 78d] toujours sous système 
HT11-V03. 


3) le système [VLISP-8 [CHAILLOUX 79al, est concu pour le micro-processeur 
Intel-8080 [INTEL 77al et Zilog-80 [ZILOG 781. IL est disponible sous ie 
système de développement ISIS-II [INTEL 77b] et TRS80 Level II [TRS 781. 


Chacun de ces systèmes représente une catégorie matérielle spécifique : 
gros système pour le  PDP-10, mini-ordinateur pour Le PDP-11 et 
micro-ordinateur pour le 8080. Les différences entre ces matériels sont 
considérables. Nous évoquerons les points suivants : 


- la taille des mémoires. Le PDP10 permet d'accéder à 256k de 36 bits, le 
PDP11 à 28k de 16 bits {Note 1} et le 8080 à 64k de 8 bits. 


- la vitesse d'exécution des instructions. Le transfert dans un registre 
du contenu d’un mot mémoire demande (indépendemment du nombre de bits 
transférés) 1.06 micro-sec dans un PDP10-KI, 3.2 micro-sec dans un 
PDP11/40 et 4.5 micro-sec dans un 8080-2Mhz. | 


- la puissance des instructions. Les jeux d'instructions de ces machines 
n'ont pas la méme puissance ce qui amène à utiliser un nombre 
d'intructions plus ou moins grand. Par exemple pour la réalisation de 
L'atlocation et de la construction d'un doublet de liste (le module 
CONS), il suffit de 2 instructions du PDP10 (qui occupent chacune un mot 
mémoire de 36 bits) alors qu'il faut un sous-programme de 9 instructions 
pour le PDP11 (chaque instruction nécessite de 1 à 3 mots de 16 bits) 
occupant un total de 12 mots pour l'appel et l'exécution du 
sous-programme. Quant aux performances du 8080 elles sont encore plus 
mauvaises puisqu'il faut un sous-programme de 21 instructions, qui 
nécessitent chacune de 1 à 3 mots de 8 bits) occupant un total de 30 mots 
mémoire. : 


{Note 1} ce nombre inhabituel de k mémoire (28k) provient du fait que Tes 
entrée/sorties sont réalisées en memory mapped I/O sur 4k mots, qui ajoutés 
aux 28k mémoire conduit bien à un espace adresse de 32k mots. 
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Malgrés leurs différences, il a été possible d’implanter sur toutes ces 
machines un système [VLISP, tel celui que nous décrire dans cette étude. Ces 
différents systèmes ne se différencient que par des vitesses d'exécution e 
des espaces mémoire différents. 


Enfin, le champ d’application du système est extrêmement vaste. Ses 
principales applications récentes recouvrent les domaines suivants : 


- l'amélioration et la correction de programmes avec le système PHENARETE 


[WERTZ 791. 


- la méta-interprétation de programmes récursifs avec Le système CAN 


[GOOSSENS 791. 
- les algorithmes d'unification IHULLOT 791]. 


- la synthèse de programmes à partir d'exemples avec le système SISP 
[LJOUANNAUD 771. 


- la compréhension de programmes avec le système RAINBOW IGREUSSAY 79al. 


- la synthèse d'images colorées telle qu'elle est pratiquée par le groupe 
Art et Informatique de l'Université de Vincennes [AUDOIRE 761, LHUITRIC 
761 


- l'aide à l'éducation des enfants retardés avec le système LOGO/LISP 
[WERTZ 791. | | 


- les outils de conception de machines [CHAILLOUX 78b, CHAILLOUX 79b1. 
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Resumé : 


Un important courant de | recherche en Intelligence 
Artificielle met aujourd’hui -L'accent sur le développement 
d'outils visant à automatiser partiellement la compréhension de 
programmes. Ce courant se situe actuellement à la croisée de 
trois directions de recherches très actuelles : théorie de la 
programmation, développement d'outils de mise au point 
interactive, interrogation sur les processus psychologiques mis 
en jeu dans l'activité des programmeurs experts. Ces recherches 
doivent déboucher sur L'automatisation partielle de la 
documentation de systèmes ainsi que sur des outils très puissants 
d'aide au développement de grands programmes : correction et 
maintenance. Il paratt indispensable, en préalable à la mise en 
place de systèmes de compréhension automatisés, de recueillir et 
de systématiser des données concernant le comportement de 
programmeurs experts, en situation de compréhension et d'analyse 
de programmes. Nous décrirons une expérience de compréhension 
dont l'analyse des résultats indique la difficulté, pour les 
programmeurs, de manipuler des représentation multiples sans 
outils appropriés d’aide à la programmation. Nous conclurons par 
L'examen d’un système de compréhension automatique, utilisant un 
ensemble de représentations multiples pour un même programme, et 
fondé sur un ensemble de régles de traductions entre 
représentations récursives et représentations linéaires. 


MOTS-CLES: 


mise au point, MLISP, programmation interactive, système RAINBOW, 
compréhension automatique, représentations multiples, psychologie 
de la programmation. 
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1.0 Introduction 


La recherche en Intelligence Artificielle est essentiellement définie par la 
programmation effective de certains modèles de comportement, pour une grande part 
d'ordres linguistiques, conceptuels et sensori-moteurs. 


La mise en oeuvre effective de ces programmes permet de tester et de falsifier très 
rapidement ces  modéles : la construction et la vérification d’hypothéses 
s'apparentant très fortement, et allant même jusqu'à s'identifier avec le processus 
de mise au point de programmes. Des structures de données et de contrôle inédites 
doivent ainsi pouvoir être érès rapidement mises en oeuvre, structures dont 
l’ensemble constitue ce qu’on pourrait nommer des langages provisoires, très 
dépendantes du modèle de comportement que la construction du programme d’ Intelligence 
Artificielle permet de valider. Le modèle se révélant en premiere approximation 
inadéquat, partiellement ou totalement, la correction où la reconsidération du modèle 
induisent alors l'abandon ou la modification drastique des structures évoquées plus 
haut. Elles conduisent dans des délais très brefs à la | conception et 
L’ implémentation de nouveaux objets pour lesquels le même processus se rèitére 
jusqu'à stabilisation du modèle. CIE "e Asia ee oe 


C’est très naturellement dans ce type de programmation instable dont la rapidité est 
encore accentuée par sa mise en oeuvre interactive que se révèlent les plus 
nécessaires des outils-systèmes de développement, visant à rendre automatiques la 
compréhension, documentation et maintenance de programmes. De tels systèmes doivent 
rendre automatiques, partiellement ou totalement, la détection et la correction des 
innombrables micro-erreurs inhérentes à La très grande taille des programmes 
développés en mode interactif. 


Les systèmes de compréhension de programmes doivent permettre de faire coexister 
plusieurs représentations du même programme en développement : ces systèmes doivent 
jouer le rôle d'outils de documentation  incrémentale, d’outils de lecture 
d'intentions de programmes et de production automatique de leurs propriétés. \ 


Nous faisons l’hypothése qu'il doit exister une continuité entre le données qui 
seront livrées par l’observation systématique du comportement de programmeurs experts 
en situation de compréhension et les nouveaux outils, dits de compréhension 
automatique de programmes qui commencent à apparaître: dans les deux cas, il s’agit 
de rendre visibles des comportements en rendant explicites les représentations sur 
lesquelles ils sont fondés. Un système de compréhension automatique original sera à 
cette occasion présenté, le système RAINBOW  (Greussay 1979). Nous examinerons 
également, à partir d'un cas concret, les difficultés liées à la comprehension 
automatique lorsqu’on la compare à celle mise en jeu par des programmeurs. 


Le langage de programmation LISP est actuellement le support massif de telles 
expérimentations, c'est pourquoi la plupart de nos exemples seront exprimés en 
Langage [LISP] 10 (CHAILLOUX 1979) dont l’environnement de programmation très complet 
illustre bien la nature des outils d’aide à la programmation qu’on peut attendre d’un 
système LISP contemporain. | 


2.0 De l'observation à la compréhension 


L’expérience de la programmation en Intelligence Artificielle doit nous amener 
à reconsidérer le point de vue actuel qui consiste à rejeter la mise au point de 
programmes et ses outils, au profit d’une validation préalable par preuve de la 
correction, partielle ou totale, de ses spécifications à différents niveaux 
d'abstractions. | 


Outre que la faillibilité n'en est certes pas absente (GERHART 1976), que les erreurs 
de programmation constituent en elles-mêmes une source de données considérable et 
encore fort mal connue sur les processus intellectuels mis en jeu en programmation 
(SUSSMAN 1974), La pratique de la programmation en Intelligence Artificielle ne nous 
permet pas de mésestimer l'importance de la mise au point (De MILLO 1979). 
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| En programmation à long terme, le plus souvent interactive, parfois 
quasi-improvisee au terminal, en tout cas profondément incrémentale, la validation 
préalable des programmes ne semble pas être une activité prioritaire. Nous avons 
plus urgemment besoin d’un ensemble cohérent d’outils de mise au point de programmes, 
ensemble totalement intégré 


1) aux interprètes qui interprètent ces programmes sous divers modes 


2) aux éditeurs (CICCARELLI 1978) qui en permettent L’ introduction et La 
modification. 


Dans les cas simples, il semble qu’en programmation interactive, les étapes de mise 
au point, d'essais, de modifications, voire de commentaires de fragments de 
programmes peuvent être anticipées, et en quelque sorte comprises et résumées par de 
tels systémes. Les outils classiques de mise au point en LISP permettent d’observer 
Le comportement des programmes. Pouvons-nous les étendre a l’observations des 
comportements des programmeurs? Un tel système d’aide à la mise au point pourrait 
fournir, de surcroît a sa fonction d'aide à la programmation, cet instrument 
d'observation et d'enregistrement de l'activité d’un programmeur au cours de sessions 
interactives. Nous faisons l'hypothèse qu'il existe des régularités observables dans 
les cycles de mise au point. .... - MEN use ae EMEN 


Reste oue les outils classiques d'observations en LISP (traces et intervenants 
de type ADVISE), s'ils ont une puissance opérationnelle considérable, laissent leur 
utilisateur devant un vide sémantique total. Pour passer de l'observation à la 
compréhension, de nombreuses questions doivent être considérées: 


1) concernant les erreurs de programmation: comment étudier et classifier les 


erreurs? quelles erreurs doit-on et peut-on capter? quelles erreurs sont 
anticipables (WERTZ 1979)? 


2) concernant la compréhension de programmes: comment rendre explicite le 
fonctionnement d’un programme correct ou non? comment automatiser la compréhension 
de programmes simples: un programme LISP d'une certaine ampleur sera composé en 
majeure partie d’un trés grand nombre de fonctions auxiliaires très courtes: 
L'expérience indique que la plupart des erreurs difficiles à déceler interviennent 
dans le détail de rédaction de ces fonctions auxiliaires. Comment rendre ces erreurs 
évidentes en livrant automatiquement l'intention de ces fonctions au fur et à mesure 
de leur frappe au terminal? 


3.0 Représentations, Compréhension, Mise au point 

Que signifie l’énoncé concevoir un programme ? 

Voici une réponse partielle issue de la pratique de la programmation en Intelligence 
Artificielle : concevoir un programme, c'est en mettre au point un autre déjà connu 


(SUSSMAN 19/5) . Ce point de vue a été repris récemment dans une perspective plus 
théorique par (DERSHOWITZ 1976). 
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Le point de vue de la mise au point implique qu'en un certain sens, un programme 
n'est ni juste ni faux. Ni juste, car toujours susceptible d’être modifié, amélioré 
ou étendu, à mesure que surgissent de nouveaux besoins ou que s'approfondit la 
compréhension du problème dont le programme est Le modèle. Ni faux, car toujours 
susceptible d’être tracé et édité. 


Ainsi le point de vue de la mise au point met l'accent sur t’ubiquité des 
modifications de programmes, et donc des modifications de représentation et de 
compréhension. 


Une expérience de compréhension 


En 1977-1978, nous avons tenté de repérer concrétement quelques unes des 


difficultés de la compréhension de programmes, à travers une expérience menée sur un 
cas trés simple. 


On notera que des expériences de ce type ne visent à rien d'autre qu’à apprendre à 
recueillir des données, des observables des processus psychologiques mis en jeu en 
programmation. Ces processus sont encore trop mal connus pour fixer prématurément 
une systématisation de telles observations. 


Nous avons soumis à plusieurs programmeurs de haut niveau la fonction Suivante, avec 
pour mission d'en découvrir l'intention. 


(DE SKE (L R) (COND 
CCATOM L) NIL) 


AEE ((MEMQ L R) T) 
quem MUN ((SKE (CAR L) (CONS L RD T) 
NUN (T (SKE (CDR L) (CONS L R))))) 


L'expérience consistait à présenter la fonction sans autre commentaire en laissant 
les sujets réfléchir quelques minutes, puis à compléter cette fonction par des thames 
présentés successivement, certains très intuitifs, d’autres plus formels, éléments de 
connaissance susceptibles d'en faciliter la compréhension. 
Theme 1:  L'appel initial de SKE est 

(SKE une-Tiste-L NIL). 
Thème 2 : Les deux arguments de la fonction standard MEMQ peuvent être des Listes. 
Theme 3 : SKE décèle des effets de bord, antérieurs à son application 
Theme 4 : L est une Liste circulaire 
Théme 5 : Soit x et y deux cellules de liste, et la relation 

X << y 
St y= (x. 2) ou (z . x 
ou 


si — X << (CAR y) ou X << (CDR y) 


Une Liste est non-circulaire si, pour deux de ses cellules x et y 
on n’a jamais simultanément 


x << y et y << xX 
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Un seul des sujets participant à l'expérience découvrit la destination de SKE des la 
présentation du thème 3. La présentation du thème 5 fut nécessaire à l'un d’entre 


eux. Tous les autres sujets donnèrent la réponse correcte lors de la présentation du 
theme 4. 


Quels furent les éléments observés? 


Le thème 3 indique déjà nettement que L ou une de ses sous-listes est circulaire: 
une liste circulaire doit étre construite par la mise en jeu des primitives RPLACA et 
RPLACD. Le premier sujet ayant décelé l'intention de SKE programmait depuis quelques 
jours une routine d'impression élégante de listes circulaires. 


Le thème 4 est positif, Le thème 5 est négatif: LL indique ce qu’une liste 
circulaire n'est pas. Le sujet ayant attendu Le thème 5 pour Livrer une réponse 
correcte admit volontiers qu'après l'avoir considéré un instant, il perdit de vue le 
fait que la fonction SKE est booléenne. 


Tous les sujets firent cependant plusieurs observations pertinentes au cours de 
L'expérience. La clause 4 fut déclarée par tous itérative, opérant le balayage de L 
dans. Le sens .des CDRs, et la clause 3 récursive, balayant.L.dans.le sens des CARs. 
L'analogie avec le schéma de la fonction EQUAL fut unanimement constatée. 


Le thème 1 semble avoir provoqué un brouillage de représentations: La variable R fut 
bien reconnue comme un accumulateur, la représentation statique de son contenu a 
fait, de l'avis général, probléme. Une fois l'accent mis sur l’aspect dynamique de 
sa construction, la destination de R est devenue pour chacun évidente. 


Qu'en conclure ? 


L'expérience a mis en valeur des difficultés conceptuelles liées à des interférences 
de représentations 


1) interférence entre le schéma récursif de SKE et la représentation itérative 
qu'entraine la mise en jeu d'un accumulateur: la variable R retient tous les CDBs de 
toutes les sous-listes de L, mais R est testée dans la condition d'arrét. 


2) interférence entre construction et rétention. CONS construit une nouvelle 
structure, MEMQ teste à la clause 2 l'identité des deux listes: L la liste courant 
examinée, et une sous-liste de | recueillie dans R à une étape précédente du 
balayage. | | 


Cette interférence a fait perdre de vue à nos sujets que MEMQ utilise EQ, qui teste 
l'identité physique de deux objets, indifférement atomes ou Listes, par comparaison 
d'adresses. Ce test d'identité physique a rendu vaine la tentative d'analyse, par 
nos sujets, de la structure interne des sous-listes de R. 


De plus une interférence de représentations spatiales a dû jouer: entre le caractère 
arborescent de L, impliqué par le schéma de type EQUAL de SKE; et le caractère 
Linéaire de R, construite par CONS successifs. | 


3) enfin interférence de type manipulatoire: L est décomposée en (CAR L) et 


(COR L) au cours du balayage. Mais L n'est pas décomposée lors de sa composition par 
CONS dans R. 
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4.0 Un systéme de comprénension automatique 


L'étude précédente nous a indiqué quelgues-unes des difficultés liées à la 
compréhension de programmes dont l'intention est inconnue. Nous examinerons à 
présent queiques unes des possibilités offertes par un systéme de compréhension 
automatique de programmes spécialisé dans la lecture d'une classe restreinte mais 
trés utilisée de fonctions de construction en LISP. Le système RAINBOW  (GREUSSAY 
1979), totalement interactif, sert de système frontal à VLISP] 10. Il permet ta 
traduction immédiate des fonctions introduites au terminal dans deux types ce 
notations formelles, exprimant l’une le calcul récursif effectué par ces fonctions, 
l’autre le résultat générique Livré à La suite d’appels symboliques. Nous na 
décrirons pas ici le processus de transformation des appels symboliques en 
visualisation d'intention mais nous l'illustrerons par des exemples d'utilisation 
pratique. 


Comment rendre visible l'intention d'une fonction de construction auxiliaire? 


Nous introduirons à cet effet deux notations indicielles 


1) linéaire 


Elle sera utilisée pour exprimer les résultats génériques ou intentions des fonctions 
analysées: elle exprime des caractéristiques de séquences. 


Cette notation est une spécialisation de celles employée dans (GOOSSENS 1979). 


[i Ei] sdf (El E2 ... En) 


1 
EXEMPLES: 
n 
(CAR 1 Eil) K EI 
l 
n n 
(CDR r! Eil) KF i Ei] 
l 2 
n n 
(CONS ET 1 Eil) XF | Eil 
> 
n n 
(DCONS X | Eil) XF cl [X . Eill 
l i 
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e) recursive 


Elle sera utilisée pour exprimer le calcul récursif effectué par la fonction. Elle 
prendra la forme générale: 


n 
LC... — ... ) expression-d'arrét 
1 


qui indique n niveaux d'imbrications d'appels s'achevant sur l'expression 
d'arrêt (n étant la longueur de la Liste qui sera la valeur de la 
variable de récursion). 


EXEMPLE 


Le système RAINBOW traduit, en mode interactif, la définition de fonction 
suivante 


(DE append (X Y) 
(IF NULL X) Y 


(CONS (CAR X) 
(append (CDR X) ¥)))) 


sous la forme schématique 


A —— 
| | 
i (CONS Xi — Y 
1 
qui résume l’expression imbriquée 
(CONS X1 (CONS X2 ... (CONS Xn Y) ... )) 
i-l 
avec Xi =df (CAR (CDR X) 


n 


: | 
| [j Xj] -df X 


[j Xj] =df (CDR X) 
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Voici deux exemples d’utilisations interactives de 
automatique de programmes, le premier assez simple, 
complexe. | 
EXEMPLE 1: 

L'utilisateur introduit la définition suivante: 
(DE f (X Y) 
CIF (NULL X) NIL 


(APPEND (g (CAR X) Y) 
(f (CDR 20 Y)))) 


que le systéme traduit immédiatement en 


n 

| | 

i (APPEND (g Xi Y) -) NIL 
| 

1 


puis la définition suivante 
(DE g (A Y) 
CIF (NULL Y) NIL 


(CONS (LIST A (CAR Y)) 
(g A (CDR Y))))) 


traduite alors en 


tt 


n 

| | 

i (CONS [A Yil — NIL 
| 

1 


puis l'utilisateur livre à RAINBOW l'appel symbolique 
(f Gxlistx A) CkListx B5) 
qui se résout sous la forme linéaire 


| 

[i j [Ai Bjll 
| 

1 


A —Á Y 


qui révèle l'intention de la fonction f: 


RAINBOW en 


Le 


second 


f construit le produit cartésien de ses deux listes-arguments. 
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Le processus de résolution sous forme linéaire 
réduction de représentations récursives en des 
Celles qui ont été mises en jeu dans l'exemple 


- la définition de la fonction g elle-même. 


- la régle RCI: 


n 
| | 
t (CONS Et - > NIL LE 
| — 
1 
- la régle RAT: 
| 
(APPEND [Ei] — > NIL E 


LA use prm mj 


Le système RAINBOW Livre ainsi successivement : 


? (f Grlistx A) (xlist B)) 


utilise un ensemble de 
représentations linéaires. 


régles 


précédent sont: 


Li Ei] 


[i Eil 


Les lignes précédées de "?" sont introduites par l'utilisateur 


m | 


| | 

(G Ai tj Bj1) -) NIL 
| | 
1 


p all 


a s 
APPLYING... G GIVING... 


M MÀ 3 
m 
m 
U 
UO 
rr 
= | 
O 
Be me E: 


APPLYING... RCI GIVING... 


m | 

| | 

[j [Ai Bjl] — NIL 
| = 

1 


APPLYING... RAI GIVING... 


[Ai Bjl] 
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| | 
j (CONS [Ai Bj] -) NIL -) NIL 
- 


La Forme linéaire obtenue 


de 


EXEMPLE 2: 


Cherchant à visualiser l'effet d'une récursion assez 
complexe, l'utilisateur introduit au terminal: 


? (DE vecmat (E) 
(IF (NULL E) NIL 
(CONS E (DCONS (CAR E) 
(vecmat (CDR E)))))) 


n | 


n 
| | | 
i (CONS [j Ej] (DCONS Ei -)) NIL 
| 
1 


D 


? cl (vecmat Cklistk XD) puis un appel symbolique 


n | 
| | 
(CONS i Xj1 (DCONS Xi -)) NIL 


mn | 


K 
all 
PPLYING... RDC4 GIVING... 


n 

| 

| 

L 

| | 
1 i 
0 

a 

A 

L-1 n 


n 

| 

(CONS j (CONS Xj — Ik Xk] -) NIL 
1 


APPLYING... RC1 GIVING... 
i-l n 

| | | 

j (CONS Xj - Ik Xk]] 
| "E 

1 


L 


APPLYING... RC2 GIVING... 


n i-1 n 
| | | 
E [j Xj i Xk] ] 
| 
1 1 i 


APPLYING... RINDI GIVING... 


n 

| 
Lj Xji] La Forme linéaire finale 
| 

1 
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5.0 Conclusion 


L'examen des nouveaux outils d'observation et de compréhension disponibles en 
LISP nous amène à infléchir notre pensée sur la programmation: comme le suggére 
(WINOGRAD 1973) il semble aujourd'hui assez net que l’activité principale en 
programmation n'est plus esssntiellement la création de programmes nouveaux, mais 
bien plutôt l'intégration, la modification et l’élucidation de programmes déja 
existants. Par ailleurs de tels outils donnent à penser que la notion de langage de 
programmation n'est plus aussi nette qu'auparavant, en ceci que la distinction entre 
langage et environnement de programmation n'est plus clairement fixée. Nous 
attendons des développements à venir qu’ils permettent la mise en jeu, pour le même 
programme, de représentations multiples, autorisant la programmation directe par 
manipulation de représentations très proches de l'intuition du programmeur. Cette 
intuition peut varier au cours du développement de programmes d'une certaine ampleur. 
Nous attendons des nouveaux systèmes qu’ils suivent au plus près cette intuition 
variable, en rendant interactivement cette intuition visible. | 


Dans cette perspective, le problème de la mise au point nous paraît être de nature 
essentiellement interprétative: concernant moins le texte statique d’un programme 
qu’un ensemble très mal connu de processus intellectuels. Nous aurons à l'avenir 
besoin d’un instrument qui nous permette d’observer ces processus. Les données 
recueillies par un tel.instrument peuvent nous permettre d'inférer la structure. 
interprétative qui manipule, modifie et combine les représentations de connaissances 
en programmation qui sont mises en jeu implicitement par les programmeurs. | 
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Abstract : 


While building or understanding large LISP systems, many small 
auxiliary functions . are... often . subject... to . errors or 
misunderstanding, in the case of very involved recursions. 
RAINBON is a specialized program understanding system able to 
reduce automatically such sets of recursive functions to a form 
where the goal of these sets are clearly displayed. RAINBOW can 
display interactively the goal-forms into two sets of new 
external 2-dimensional notations: recursive and linear. Program 
understanding is obtained by the translation of the original set 
of LISP functions into the open recursive notation, then by 
elementary symbolic evaluation yielding closed linear forms of 
the original functions. Those linear forms are exactly the goals 
wanted. RAINBOW operates efficiently on a definite class of LISP 
functions, and uses an extendable set of reduction rules, which 
constitute the symbolic interpreter. RAINBOW can be used 
interactively if a user want to verify that a set of functions 
perform its intended goal, or can be incorporated easily as a 
specialized component of a larger program understanding system. 
This paper shows how RAINBOW operates on sets of recursive 
functions building combinatorial objects. 


KEY-WORDS : 


automatic program understanding, program debugging, [VLISPI, RAINBOW 
system, multiple representations, program transformation, 
symbolic interpretation. 


http:;//www.artinfo-musinfo.org Rapport ATP 4273, octobre 1980, page 44 / 124 


1. INTRODUCTION 


RAINBOW is a specialized interactive program understanding system. It asks from its 
user a set of recursive functions definitions, then extracts and displays graphicaliy 
its goal, in terms of properties of Lists viewed as sequences. 


To display the goal of a definition set, we have introduced two classes of 
2-dimensional external notations which are implemented within RAINBOW. The open 
notation is a compact notation for recursive programs or data structures, the closed 
notation expresses intrinsic properties of linear sequences in term of generic 
properties of their elements. 


Program understanding is obtained by the translation of the original set of functions 
into the open notation, then by elementary symbolic evaluation yielding closed forms 
of the original functions. The closed forms are exactly the goals wanted. 


Presently, RAINBON can reason about classes of data-structures as lists considered as 
sequences, extensions to recursive LISP functions operating on other classes of 
data-structures are considered. 


RAINBOW can be used either as a front-end of a LISP system, or as a specialized part 
for lou-level understanding of sequences, in a larger program understanding system. 
An analogy with low-level machine vision is here in order: scene analysis has to 
rely Upon intrinsic properties of pictures, as incidence, gradient, ttlumination or 
texture. We believe that a large program understanding system must also rely upon 
intrinsic properties of the data involved in the programs tentatively analyzed. 


A programming apprentice system (RICH 1979, WERTZ 1979), if used interactively, must 
have the capability of focusing in a visually understandable way, to lower levels of 
plans. The plans diagrams described in (SHROBE 1979) seem promising either at very 
high level of inter-module analysis, or when the goal of a module is intermixed with 
other goals, or when global side-effects are involved. However these plans, 
displaying very well the global course of actions involved in analysed programs, do 
not seem appropriate to be used for lower-level modules because they do not allow to 
display the structure of the elementary goals for simple modules. Unfortunately, in 
very large systems, it seems that the simplest modules are the most. error-prone. 


RAINBOW allows the user to check. immediately, in a visually understandable way, the 
goal of a set of functions definitions. The user does not have to provide an 
assertion to verify ,about his definitions set, because in a sense RAINBOW is 
precisely reducing this set to its assertion. 


RAINBOW is an implemented system written in [LISP] (CHAILLOUX 1978) running on DEC 
KI-10, and PDP 11/40. The external notations can be visualized on any kind of 
display or hard-copy terminal. 


2. QUERVIEW OF THE RRINSON SYSTEM 
The symbolic interpreter: 


The symbolic interpreter is essentially a production system having an initial fixed 
set of reduction rules for the handling of LISP sequences. When a user submits a new 
function definition to RAINBOW, the reduced closed linear form obtained as a goal is 
incorporated by the system into the set of rules. The interpreter is able to expand 
every inner function call with the replacement part of the corresponding rule along 
with the renaming of variables when necessary (a-conversion). As in (BOYER 1977), 
The interpreter operates iteratively until no more rule can apply to the reduced 
form. 


The definitions entered can be also called within the LISP Lterpreter, and every step 
of. the reduction can be interactively reversed, providing an history of the 
reduction. Also at user-level, RAINBOW can handle symbolic function calls. 


The process of resolution into linear forms uses a set of reduction rules for the 
translation of recursive representations into linear representations. 


The reduction set of rules for a LISP function is expressed into tuo neu classes of 
graphical notations for recursive programs and data, and for linear sequences. 


Recursive and Tinear external notations: 
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It is used to express generic 
expresses characteristics of sequences. 


EL BI dT XE 


context of RAINBOW, the range 


EXAMPLES: 


(CAR 


(CDR 


(CONS E; 


(REVERSE 


n i-1 
| | 
Ci Ej Lj 
| | 
1 1 


immediately following it. 


n 1 
| | 
[i E,]> re [i 
| | 
1 n 


n 


ES ls 


1 Ez ... En) 


of the index variable ls 


À more complex example is: 


| 
(CONS A LO k Lk11 E 
| 


i+] 
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results or goals of the analysed 


: The letter i is an "index variable" ranging from lower to upper indices, here from 1 
| to n. When one of the indices is 0, 


the 


functions: Lt 


This notation is a 2-dimensional specialization of the one used in (GOOSSENS 1979). 


the notation denotes the empty sequence. In the 


LISP expression 


(CONS A Lp311 


=45= 


2) recursive 


It is used to express the recursive computation performed by the function. Tt has 
the general form: 


n 

| | | 

ai - Bi a =df Qi ... On OQ Gy... Bi 
1 


where ai, fi, and ð are parts of LISP expressions as well as linear or recursive 
forms. The recursive notation is essentially an indexed context-free grammar rule. 
It expresses n levels of nesting of function calls terminating with the expression à, 
When the RAINBOW system uses the recursive notation, n is the Length of the List 
Which is the value of the recursion variable. The crossing of lines in the notation 
denotes a self-reference to the entire expression with the index variable progressing 
one step towards the highest index. | 


As an example RAINBOW translates interactively, the following function definition 
|. «DE append (X Y) 
CIF (NULL X) Y 
(CONS (CAR X) | 
(append (CDR X) Y)))) 


into the recursive form 


| 
(CONS X; — Y 


Ed mes mtt 5 


which schematizes the nested expression 


(CONS X, (CONS X2 ... (CONS Xn Y) ... )) 


where X, translates (CAR (CDR 00) 
n 
Lj Xil translates X 
i 
n 
1 Xi] translates (CDR X) 
a 


It happens that the goal of the append function is itself expressed into the 
reduction rute RC2: 


E pee 3 


m n m 
| | | | 
(CONS Xi - > [j Vi] E [i Xi j Yul 
I | | 
1 1 1 
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3. USING RAINSOM: A SIMPLE REDUCTION 


RAINBOW can be used interactively for the automatic documentation of programs 
as soon as they are typed, as advocated by (WINOGRAD 1979), In the following 
example, RAINBOM is reducing to its goal a set of tuo simple recursive functions. 


The user types the following definition: 
(DE f (X Y) 
CIF (NULL X) NIL 


(APPEND (g (CAR X) Y) 
CF (CDR X) 1022) 


that BAINBOW translates immediately into 


| | 
(APPEND (g Xi Y) -) NIL 


PI que J 


then the following definition 


(DE g (A Y) 
CIF (NULL YO NIL 
(CONS (LIST A (CAR Y)) 
(g À (CDR Y))))) 


is translated into 


| 
(CONS [A Yi] — NIL 


E pre 3 


then the user types to RAINBOM the symbolic call 
(f Cxlistx A) Cklistk B2) 


uhich is reduced into the Linear form 


| m 

| 

li j [A; Bill] 
| | 

1 1 


which yields the goal of the function f: 
f builds the car£esian product of its tuo argument-lists. 
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The reduction set of rules which has been used in the previous example is: 
~ the definition of the function g itself. 


- the rule RCI: 


Pde e —Ák 


n 
| | 
(CONS E; - ) NIL KP [i El] 
| 
1 


- the rule RAT: 


oe 


n 

| | | 

i (APPEND à; -) NL p 
| 

1 


rA 
e pa. memo 3 


So the RAINBOW system yields in succession : 
? (f Grlistx À) Gslistx B)) 


Lines beginning with "?" are typed directly by the user 


n 
| m | 
| (APPEND (G A: 1 B;1? 5 NIL 
| | 
OK 

? ap all 


a 
APPLYING... G GIVING... 
| MESE |] 


n 

| Qd | | 

i (APPEND j (CONS IA; Bj] — NIL -) NIL 
| | oe 


APPLYING... RCL GIVING... 


n 

| m | 

(APPEND | LA: B;j11 L, NIL 

| d] - 
APPLYING... RAL GIVING... 


il 

| 

Li j IA, Bil] The Final linear form 
| | 

11 
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4. UNDERSTANDING COMPLEX REDURSIONS 


Sometimes recursion can be quite involved, as in the following square 
generator: 


(DE vecmat (E) 
(IF «NULL E) NIL 
(CONS E 
(DCONS (CAR E) (vecmat (CDR E)))))) 


where 
n n 
| | 
(DCONS « [i ED E [i (CONS «a E421 
| | 
1 1 
The goal of VECMAT extracted by RAINBOW is: 
n n n 
| | | 
(VECMAT d Eid) n u Li E11 
| 
1 | 1 1 


The body of VECMAT is slightly generalized to obtain the main reduction rule: 


¿AA IB 
1 | | LE | 
i (CONS ati (DCONS E, - 2) NIL Dp i (CONS j (CONS Ej i y ri - ) NIL 
| Mu | “fi 
1 1 1 


which by the rule RC1 is reduced itself to: 


1 


ps 
| | 
= Ci j (CONS Ej - 2 ai (rule RDC4) 
E a 
1 


P a 


n 
| 

Nou if ue sets aq, to [k Ex], RAINBOW obtains the linear form for VECMAT by: 
| | 
i 


1 n n 1 n n n 
| | | 
E; k Ekl]? Ek? Ii Cj El] 
> | .| | 
L | 1 


1 


E | | ld 
E 

[i j «CONS E; - ) Ik E&11 17 fi Cj 
E | 
11 i 1 


The final result being obtained by the reduction rule RIND2: 


i-l n n 

| | | 

li Xi | Xl | n Xil 
| 

1 i 1 
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«bs 


The same reduction process can be used to obtain the goal of the function partinsert, 
main component of a recursive partition generator. Though very usual this style of 


recursion is ratner difficult to visualize, and is very error-prone. 
example displays a session with RAINBOM: 


The user types the definition 
? (DE partinsert (X E) 
CIF (NULL E) NIL 


(CONS (CONS (CONS X (CAR E)) (CDR EDD 
(DCONS (CAR E) (partinsert X (CDR £)))))) 


hat RAINBOM £ranslates into 
n | 


| | 
(LAMBDA (X E) (CONS [(CONS X E,) j Eg] (DCONS E, -)) NIL) 
| 


t 
n 
| 
| 
L 
| — 
1 i+] 

Then the user provides the symbolic call 


2 cl (partinsert A Cxlistx L)) 


n | 
7 
(CONS [CCONS A Lid j L;1 (CONS L; -)) NIL 
1 | i+] — 
Then the user asks for ail reduction rules 
to be applied 
? ap all 


a 
APPLYING... RDC4 GIVING... 


i-1 n | 


— ue 


n 

| | NE 

i (CONS j (CONS L; — [(CONS A Li) k Lx] -) NIL 
| | 

1 


i+] 


APPLYING... RC1 GIVING... 


n i-1 n 

| | | | 
Ci j (CONS L; -) E(CONS A L:i) k Lx11 
| | — | 

1 1 itl 


APPLYING... RC2 GIVING... 


n i-1 n 
cl 1 L; (CONS A Li) : Lk 1] 
| | m 
OK 


The final reduced form is the goal of partinsert 


http://www.artinfo-musinfo.org Rapport ATP 4273, octobre 1980, page 51 / 124 


5. CONCLUSION 


The 2-dimensional display for formula within RAINBOW is claimed to be intuitively 


understandable by using intrinsic properties of sequences: the use of indices 
relates the length and order of the sequence to the general form of the generic 
elements. 


Along with the powerful reductions from recursive to Linear forms, we believe that 
the external notations presented here reflect our intuitive understanding of Lists 
and their properties. 


In a fast checking situation, this graphical style of verification, displaying the 
generic structure of data, gives the user excellent control over the goal obtained 
from a functions sets. 


[he extendability provided by the incorporation of every neu function definition as a 
new reduction rule in the spirit of (BOYER 1977) gives a useful tool to system design 
and programming methodology: as advocated by (GERHART 1975), the resulting schema 
and transformations that are saved will have to be ultimately organized into 
"handbooks of knouledge" about programming. 


Presently, RAINGOW is able to reason about classes of data structures as sequences, 
we are considering its extension to arrays using the rules given in (REYNOLDS 1979). 
Program understanding with RAINBON can be vieued as a kind of simplification, and its 
extension to several classes of data-structures may involve combination of decision 
procedures for several theories described in (NELSON 1978), (OPPEN 1978). 


Internally, RAINBOW is mainly driven, out of the fixed initial set, by user-provided 
rules obtained by reduction of previous definitions to their goals. Thus, the power 
of RAINBOH is strictly limited by the class of expressions that the external 
notations are able to denote. Most of the rules in the fixed initial set are 
properties of the function CONS, extended to APPEND and REVERSE. 


In the present state of the rules, RAINBOW is restricted to primitive recursive 
functions. À single recursion variable is handled within each rule : an obvious 
extension to an arbitrary number of recursion variables can be incorporated, each 
having the same pattern of sequence as an argument. 


Another extension is currently implemented to handle iterative function schema as in: 


(DE itrev (X Y) 
(IF NULL X) Y 
Citrev (CDR X) (CONS (CAR X) Y)))) 


where Y is acting as an accumulator. With such an extension, the translation of 
trev into the recursive notation should be: 


| 

| 
i (CONS Xi : yy 
| 4 


n 
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, Si. 


With this extension, checking of equivalences as: 


(APPEND X Y) = Citrev Citrev X NIL) Y) 


could be done by direct reduction as in: 


5. 


[1] 


[2] 


[31 . 


[4] 


[5] 


[61 


[7] 


[8] 


[9] 


n m n m 
| | | 
(APPEND [i Xi] D YD E? Citrev (trev [i Xi] NID Ij Y,1) 
| | | | 
1 1 1 1 


1 m 
| 
Lr (itrev [i Xil [j Y,1) 
| | 
n 1 
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Summary : This paper presents a system (PHENARETE) which understands and 
improves incompletely defined LISP programs, such as those written by 
students beginning to program in LISP. This system takes, as input, the 
program without any additional information. In order to understand the 
program, the system meta-evaluates it, using a Library of pregmatic ruies, 
describing the construction and correction of general program constructs, 
and a set of specialists, describing the syntax and semantics of the 
standard LISP functions. The system can use its understanding of the 
program to detect errors in it, to eliminate them and, eventually, to 
justify its proposed modifications. This paper gives a brief survey of 
the working of the system, emphasizing some commented examples. 


Introduct ion 


Much effort is spent on the development of tools to help programmers in 
constructing, debugging and verifying programs. From simple editors and - 
trace-packages, the trend is towards more and more sophisticated automatic 
programmers  [3,81, auotomatic debuggers  [15,17,1] automatic assistants 
[14], automatic verifiers [11,5] or even the construction of new - 
semantically more firmly based - programming languages (PASCAL, ALPHARD). 


Most of these tools exhibit some weaknesses such as 


- they impose too many constraints on the intuitions of the programmer 
(cf [61), 


they work only on a very Limited subset of possible programs (cf 
EL, 1515, 


they work only on correct programs (cf L2,111), 


Our aim in the design of our program understanding system was four-fold : 


-l- ue wanted to have a system which makes explicit the know ledge 
involved in constructing and debugging programs; 
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-2- we wanted our system not to verify the correctness of programs but 
their consistancy 


-3- ve wanted the system to provide hin£s for improving and correcting 
programs and 


-4- we wanted a practical, useful and running system. 


Thereupon we have built a program understanding system able to 
automatically correct and improve programs. This system, PHENARETE, 
assists beginning programmers during the writing and debugging of their 
programs. 


Programming errors 


The construction of a computer program can be divided into different 
steps : first, the programmer has to have a someuhat precise 
conceptualisation of the activity he disires the computer to perform. As 
quoted by Model [13], this conceptualisation doesn’t just restrain at the 
Level of overt input/output behaviour, but includes the projected programs 
manipulation of tts internal data structures. Second, the programmer has 
to conceive a method by which the intended activity may be performed. 
Third, he has to express this method in terms of a programming Language 
and, fourth, he has to communicate the program to the computer. 


This process induces 5 major types of programming errors, related to these 
different steps : lexical, syntactic, semantic, teleological and 
conceptual errors. 


Lexical errors are probably the most frequent - and more easily debuggable 
- errors. They are mainly misspellings or typographical mistakes, and are 
detectable at the word-level. They refer - in classical compilers - to 
the lexical analyser or scanner. 


Every language has rules governing the allowed forms of program 
statements. We call deviations of these rules syntactic errors. 


These first two kinds of errors, normally detected during the reading of 
the program (compilation phase), are - in this paper - invariably called 
surface errors or informalities. 


Another kind of errors is that - even uhen the syntactic form is correct - 
its meaning may be unclear, contradictory or invalid. Examples of this 
kind of errors are "division by zero", an attempt to multiply a number by 
a string or a call of a function which has no definition. We call such 
errors semantic errors. They are normally detected during the run-time of 
the program. | 


New algorithmic languages, such as PASCAL, MESA or ADA, try to detect 
semantic errors at the semantic level through "strong compile-time 
checking of data types and program interfaces". But even when they are 
detected by syntactic checking, the sources of such errors lie at the 
semantic level. 

Let us note that such compile-time checking is rather limited, since even 
such a simple error as division by zero escapes the checking if the 
divisor isn't just a constant or a variable, but an expression whose value 


http://www.artinfo-musinfo.org Rapport ATP 4273, octobre 1980, page 55 / 124 


ires Stereotyped Program Debugging : an Aid for Novice Programmers 


LS computed at run-time and the expression equals zero only sometimes. 


The fourth class of errors ue can distinguish, are teleological errors, 
which occur when the program does something, but not what vas intended. 
These errors refer to problems in the scope of the programmers’? precise 
specification of the computational scheme or algorithm. 


In our paper we call errors of the last tuo kinds deep errors or 
inconsistencies. 


À last kind of errors is met if the source of the problem is in the method 
or approach devised by the programmer to achieve the desired computational 
activity. These errors are called conceptual errors. 


Cur system, PHENARETE, analyses the text of a program and, when it detects 
informalities or inconsistencies, it constructs and proposes possible 
corrections or improvements. These modified versions of the program, 
constitute for the novice programmer, a crucial component of his 
apprenticeship : basing on examples the process of improving and 
correcting imperfect programs, and basing on models the process of 
inventing future programs. 


The originality of the system resides 1) in its ability not only to detect 
low-order errors - a standard in todays compilers - but also middle- and 
even higher order errors (i.e. semantic and some teleological errors), 
and 2) in its attempt to use the knowledge necessary to detect errors, 
also to construct possible corrections. 


Cvervien of the system 


The system takes as input the draft version of a LISP program and delivers 
as result of its treatment one or more versions of the same program, 
corrected and improved.  PHENARETE proceeds in several steps (cf fig. 
1): first a preliminary analysis of the text of the program is per formed 
in order to detect and correct surface errors. By surface errors ve mean 
errors detectable by local anlysis : simple lexical errors such as 
misspellings or parenthesis errors as well as syntactic ones such as 
errors concerning the wrong number of arguments in function calls. During 
this first analysis PHENARETE collects information for the following 
steps. Whenever it meets the name of a function (standard or user defined 
LISP function) it automatically activates a specialist, associated with 
this function, by the process of data driven function invocation [16]. 
These specialists represent its knowledge about the use and the effects of 
the associated functions. 
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mm ar 


figure 1 


The result of the first analysis - a syntactically correct program - is 
then meta-evaluated to verify the programs weii-formsdness. We say that a 
program is well-formed if it doesn't contain obvious infinite loops, 
doesn't have useless statements (i.e. statements never executed) and if 
it doesn’t contradict the set of rules incorporated in  PHENARETE. Every 
final version of the program our system delivers is a vell-formed program. 


When PHENARETE detects some informalities or inconsistencies, it annotates 
the corresponding part of the program and sends the code and the 
annotation to the repair-module, a module designed to eliminate errors 
(uith the help of stereotyped programming knowledge). The system stops 
the analysis process when not finding any more possible improvements. 


Organisation of PHENARETE 


The system is based on four main concepts : | 

-1- During the analysis of a program, PHENARETE constructs a description - 
an internal representation - of the program in terms of cognitive 
atoms. These may be considered as the nodes of a network-like 
representation of the program. | 


Each cognitive atom is composed of a set of facets uhich represent its 
different aspects, about which questions can be asked, such as 


- what type is it ? 
~ what is its definition ? 
~ Cif it is a function) what is its domain ? 


The facets are filled in during the analysis process. 

le distinguish betueen three classes of cognitive atoms, those 
concerning variables, those concerning labels and those concerning 
functions. The facets are the same for every atom inside the same 
class, but they differ significantly from one class to another. 

The representation of a cognitive atom is a set of attribute/value 


pairs, and the value V found under the attribute P of atom À is simply 
the answer the expert À can give to question P. 


-2- À set of specialists, i.e. a set of procedural specifications of the 
syntax and the operational semantics of the standard LISP functions, 
such as CAR, CDR, EQ, COND etc. | 
We distinguish between tuo different types of specialists : 

- those describing the syntax and 


- those describing the semantics 


of the associated functions. 


^ 
1 
3 
$ 
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example : specialist CAR for the syntax 


[CAR-1 CX) => 
v (& atom (CAR X) 
& type 00 = LISTP) 


v (& S-expression (CAR X) 
& type (val 00) = LISTP) 


modify X until CAR-1 OO = T] 


paraphrasing : 


CAR expects that its argument is 

- an atom 
and the type of the value of the argument is a list 

- a S-expression 
and the type of the value of that S-expression is a List 
(e.g. a function call) 

else 

CAR has to modify the argument until one of these tuo 
conditions is true 


and the specialist CAR for the semantics 


(X (meta-eval X)) 
(type (val 00) = 
(type (val 00) = 7 


-» hypothesize (X, type: LISTP) 
T -» complain (X, type : LISTP) 
action : if (exist (CAR X)) --> (CAR X) 
else (create (CAR, 20) --> (CAR X)] 


or in paraphrasing : 
CAR-N 


has an argument named X, uhich must be evaluated 
one must verify 
Lf 
the type of value of the argument is a list, all is ok 
else 
Lf the type of value of the argument isn't knoun, one has 
to create a hypothetical value of type LIST for X 
else | 
one has to call the repair-module to change the text of 


the program in such a way that the value of X becomes a 
List 
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the value of CAR is 
if 
there exists already a CAR of X, this CAR 
e lse 
one has to create a symbolic value for X, the CAR of which 
will be the desired value 


Note that the internal description constructed during the analysis of 
each user function is used to construct tuo neu such specialists for 
each user function. 


The specialists are the agents of the meta-evaluation and they- 
represent the systems Knowledge about the programming language used. 


-3- An algorithm of meta-evaluation [7] which helps the system to analyze 
each of the possible paths of the program. This algorithm is composed 
of tuo parts : | 


- a module to determine the symbolic values, i.e. since the 
meta-evaluation doesn't use concrete values in order to evaluate the 
program, it must deduce from the text of the program the type and 
the structure of the arguments of the different functions to 
evaluate. Thus our algorithm is rather different from those 
proposed in [10, 12] which receive the symbolic values as input. 


- an evaluation module, i.e. a module able to evaluate functions on 
these symbolic arguments. 


With this algorithm one unique execution is representative for every 
particular execution [12]. 


-4- À set of pragmatic rules describing general program constructs and 
stereotyped methods to repair inconsistencies. These rules formalize 
and express explicitly the knowledge activated by every programmer 
when he is reading a program. 


We do not use rules concerning the task domain of the programs : our 
intention was to build a system which does not ask for any additional 
information, i.e. which works only uith the text of the program to be 
analyzed, So that the programmer is not obliged to accompany the 
programs by comments, assertions or other specifications. The system 
should work - without any additional information - in any possible 
task domain, numeric as uell as symbolic. 


Our rules are very general and valid for every LISP program obeying to 
the follouing restrictions : 


- the names of variables, functions and labels are unique 
- each function call must be of the type "call by value" 


- the unique functional arguments permitted are explicit 
A-expressions. i; 
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We call this subset of LISP : "extended first order LISP". 


examples of pragmatic rules : 


rrr TT 
| rule of the dependence of a loop of the 
| predicate => 
| 

given s € {loop} 


| 
| 
| 
| 
iexit-test of F} | 
| 
| 
| 
| 
| 


I 


| F 
| T 
| Ÿ = {variable} so that 
| VyeY tel vct 
| then : VyeY val(y) [F11 val? (y) 

| ^ val(y) = val? (y) 

| => val(F) = undefined 
———— A A el 


in paraphrasing : 


if no variable of the exit-test of a loop is modified inside the 
Loop-body, then the loop is independent of the exit-test and either 
its execution is non-terminating or the loop will never be executed. 


À slight refinement of this rule is the following one : 


(2) 
rule of the structural well-formedness of loops => 


in a loop at least one of the variables used in the exit-test has 
to change its value inside the body of the loop, in such a way 
that its structure is simplified and converges towards the 
satisfaction of the exit-test. 


In order to use this rule, ve have implemented a small theorem prover 
which can prove the convergence by induction. As to the proof implied 
by this rule, the theorem-prover takes the. symbolic value of the 
varíables at the entry of the loop, and the modified symbolic values 
of the same variables after one meta-evaluation of the  loop-body and 
tries to prove the convergence towards the stop test. 


Let us give one last example of a pragmatic rule : 
(3) 
rule of the structure of recursive loops =>|. 


| 
| | 
F € {recursive function} | 
A = {call of F} so that AcF | 
S = {selection-clause} so that ScF | 
then : VacA -seS acs | 

| 


^ 41Sc«S so that VacA acs 
| 


paraphrasing : 


| 
| 
] 
] 
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in a recursive function, the recursive calls have to be inside a 
selection-clause, and at least one of the clauses must not contain a 
recursive call. | 


Presently ue have about a hundred rules incorporated in the System, 
dealing especially with iteration and recursion, the use of variables 
end list-processing. For almost every rule there exists a dual cna 
indicating how to modify the program in such a vay that the first one 
is satisfied. 


Soma commented exsnales 


To use PHENARETE, the user has to give the system only the text of the 
draft version of the program he wants to write, without any additional 
information Like input/output assertions, comments, plans etc. The system 
will try to understand what the user wants to do and, if necessary, modify 
the text of the programm. | 


To give some feeling hou the system vorks, let us examine some examples in 
detail : 


Our first example is a (very) erroneous version of the well knoun REVERSE 
function. Here is the actual input to the system : 


2 (P'(DE REV L1 L2 COND ULL LES A1 T RUE A1 ONS CRA A1 ED) 


PHENARETE will first perform a preliminary analysis using only its 
syntactic knowledge, i.e. the specialists for the syntax and the spelling 
error corrector. The result of this first analysis is a syntactically 
correct LISP progam, a program accepted by any LISP interpreter or 
compiler. 


Here is the actual printout of PHENARETE at this point : 


ERRCR: 

NAME --> C? ULL --> NULL) 
ERROR: 

NAME --> (? 122 --> L2) 
ERROR: 

NAME --> C? 01 --> L1) 
ERROR: 

NAME --> (0? Al --> L1) 
ERROR: 

NAME --> (C? RUE --> REV) 
ERROR: 

NAME --> €? AL --> L1) 
ERROR: 

NAME --> C? ONS --> CONS) 
ERROR 

NAME --> C? CRA --> CAR) 
ERROR 

NAME --> (2 A1 --> L1) 
ERROR 


NAME --> (7 AB --> L2) 
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SURFACES IMPROVEMENTS : 


(DE FEV (L1 LE) 
(CON 


Cf &RzU L1 (CENS CORR L3) Lg33333 


These first improvements have eliminated all the syntactic errors. 
However, at least one semantic error remains s 


Neither Li nor LZ are modified in such a way that their values 
converge towards the stop test; even with a modification of Li in 
the recursive call, the recursion won't stop since the stop-test has 
as argument L2, a List which grows longer and longer on successive 
recursive calls (rule 2). 


During every analysis, our system collects useful information about the 
program, represented in the data-base which constitutes the internal 
description of the analyzed program. Figure 2 shows the state of the 
data-base after the first analysis of the function REV. 


~---- figure 2 somewhere here ---- 


data-base after the first analysis 


figure 2 
The knowledge represented in fig. 2 can be paraphrased as follous : 


After the first analysis PHENARETE knows that REV is a recursive 
function, with tuo arguments. The first argument is called L1, which 
the system doesn't know the value of, but knous it has to be a List. 
At the recursive call of REV, the first argument is not modified. 


The second argument is called L2. PHENARETE doesn't know its value 
either. It too has to be a List. At the recursive call L2 takes the 
value of the expression (CONS (CAR L1) L2). 


As for the errors detected up to that point, most standard scanners detect 
this kind of errors, and some compilers even handle this kind of 
corrections (PL/C or CORO. 


For the further improvements, the system proceeds to a meta-evaluation of 
the current version, using as symbolic value of the arguments just the 
knowledge that they have to be lists. If further specification about the 
values is needed, PHENARETE constructs them dynamically. 


In this example, the system has - corresponding to the tuo clauses of the 
selection (COND) - to develop tuo paths, one supposing the predicate (NULL 
L2) satisfied, one supposing it falsified. 


Note that one of the main differences between standard evaluation and 
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meta-evaluation is that the knowledge derived during the meta-evaluation 
of one of the possible paths can be used during the meta-evaluation of 
every other path. 


After one meta-evaluation of the function REY, PHENARETE has constructed 
an evaluation tree of the form : 


o REV List-Li List-L2 
| 


o COND 
/ 
L2=() / Li=(al an) 
/ L2-(bl ... bn) 
/ 
O o 
result« 1 REV (al ... an) 
(CONS al (bl ... bn)) 


As noted above, the meta-evaluation stops, when it reaches a point where 
no further continuation is possible (the case of the left branch) or when 
it reaches a point where control has already passed by (which will be the 
case later on, during the meta-evaluation of the right branch of the 
tree). 


When the system meets a recursive call or an iteration, it carries on the 
evaluation just as in normal execution. Mere the continuation of the 
right branch of the tree forces the system to falsifie the first predicate 
of REV, since the symbolic value of L2 is a CONS-expression which can't 
equal NIL (the empty list). So ue find : 


o REV List-L1 list-L2 
| 
o COND 
/ 
L2=0 / Li=Cal ... an) 
/ L2=(b1 ... bn) 
/ 
O O 
result=L1 REY Cal ... am 
(CONS al (bl ... b2)) 


COND 


| 
o 
| 
| Ll=(al ... an) 

| L2=(CONS al 

| (pl ... bn) 
O 

V 


(al ... an) 
(CONS ai 
(CONS al 
(bl ... bn))) 


RE 


At this point PHENARETE has to stop the meta-evaluation : all terminal 
leaves are either end-points of the program or points already visited 
during the meta-evaluation. 
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Application of the pragmatic rules, especially those concerning recursion, 
indicates that the program won't stop, since the modification of the 
arguments isn't in such a way that they converge towards satisfaction of 
the exit-test (rule 2) : the exit-test checks if L2 is a empty list, but 
L2 grows longer during the successive recursive calls. The demonstration 
here is straightforward, but we easily realize that the power of the 
system depends crucially on the power of the incorporated theorem prover. 


Each rule is combined with an ordered set of advices as to "hou to 
correct" the non-satisfaction of the rule. The advices of rule 2 say that 
in order to correct ihe code, we have to suppose that 


-1- there is an error in the stop test or 
-2- there is a missing stop test or 
-3- there is an error in the recursive call 


The pragmatic rules as well as the advices (which are just pragmatic rules 
of correction) are hierarchically organized, from the general to the 
concrete, i.e. the application of one rule may result in the application 
of a lot of other rules. | 


In this case the first advice PHENARETE finds applicable is the third one. 
Here is another point of the system which deserves some critics : 
PHENARETE supposes that at least one of the arguments has to simplify its 
structure in the successive calls. If this isn't the case, and the system 
doesn't find an error, all is ok, but otherwise it forces a 
simplification. Here the simplification is forced by the use of the CAR 
of L1 : PHENARETE assumes the user wants to work with successive elements 
of L1, which makes it introduce the modified recursive calt 


(REU (COR LICCONS CCAR L1) Le)) 


No doubt, if the programmer didn’t want that, eventually he won't 
understand any more the correction of PHENARETE. But, in constructing the 
system ue wanted the programmer not to be obliged to give asssertions or 
comments, so we have no means to know anything about the intentions of the 
programmer (except what is explicitly stated in the code), and the 
proposed corrections may differ significantly of those used by an 
experienced programmer knowing the intentions. 


But, to justify our approach, before beginning to write the system, ve 
have systematically studied, during one year, the programs uritten by our 
students. The corrections PHENARETE proposes, are those corresponding to 
the statistically most current errors. On the other hand, we think a 
program uhich stops and delivers a result different from the intended one 
is easier to debug than a program entering in an infinite Loop.  PHENARETE 
just corrects progams in such a way that they don't abort and stop 
delivering a result, uhen executed. 


After each modification, the system re-meta-evaluates the program, to 
check if any error remains. 


In our example PHENARETE can not disambiguate this function - it does not 
know anything of the intentions of the programmer - so it gives two 
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different propositions : 
FROFGSITICA 1 
(DE REV (L1 L2) 
(CON 

CCNULL L2) LD 

CCNULL L1) L8) 

CT (REU (CDR 11) COONS CCAR LD £23333) 

AT LERST YOUR FUNCTION SEEMS OX. 

In this first proposition, PHENARETE supposed the given stop-test correct, 


but assumed that the user omitted a second stop-test in case the second 
argument is not NULL at the initial call of REV. 


PROPOSITION 2 : 
(DZ REV (L1 Le) 
CCOND 
CCNULL L1) Le) 
(T (REV (CDR L1) (CONS CCAR L1) £23333) 
AT LESST YOUR FUNCTION SEEMS OX. 

In this second proposition, PHENARETE supposed that the user inadvertently 
inverted the arguments of the stop-test, so it inverts the two arguments 
L1 and L2. 
PHENARETE secures that the tuo corrected versions of the initial 
draft-program (which are not identical) will stop and deliver a result 


when executed. 


The data-base after the completion of the analysis of REV is represented 
in figure 3 (only for the second version) : 


figure 3 here somevhere 


data-base after the analysis 
figure 3 


Two sources of information are available after the complete analysis of a 
program : 


- the program as an executable algorithm 
- the description of the program in the data-base 
This data-base doesn't describe 'how' or 'uhat' the program computes, but 


gives valuable indications on the conditions which have to be verified if 
the program is activated and on those which are verified after its 
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execution. 


This description is used to construct new specialists, in order not to 
reanalyze the function if it is called by another one. 


Here are the tuo specialists : 


specialist REV for the syntax 


[REV-1 (O0 => 
& ( 


atom (CAR 20 

& type (CAR X) = LISTP) 
S-expression (CAR 70 

& type (val (CAR X)) = LISTP)) 
atom (CADA X) B 
type (CADR X) = LISTP) 
S-expression (CADA X) 
type (val (CADR X)) = LISTP 


X until REV-1 OO = T 


specialist REV for the semantics 


[REV-N => 


arg : (X Y (meta-eval QO meta-eval (Y))) 
test : (type OO = LISTP)_ 
-> (type (Y) = LISTP) -> 
type (Y) = ?) 
-> hypothesize (Y, tvpe:LISTP) 
T -» complain (Y, type:LISTP) 
(type (X) = ? 
-> hypothesize (X, type:LISTP) 
| go test qu 
T -» complain (X, type:LISTP) 
Ms test 
action: => {LISTP, execute-symb (REV X Y)}I 


As can be easily verified, the specialists are just algorithmic 
transcriptions of the data-base. 


Now, when PHENARETE meets, during the analysis of another program, a call 
to the REV-function, it hasn't to reanalyze the body of the function, but 
it can use the specialists of REV in the same manner it uses the 
specialists of the standard function. 


Üur second example is an extremely "simplified" version of the equally 
well-known FACTORIAL function. Here it is: 
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oo oh AA 


? (GE FACT N TIMES N PROT ND 


As in the previous example, PHENARETE will first translate this 
unparenthesized expression into an vell parenthesized one 2 


SURFACE IMPROVEMENTS : 
(DE FACT (CN) (TIMES N ("ECT 0023 


This first proposition is a syntactically correct program, but 
semantically it presents some difficulties : 


-1 at the recursive call, N is not modified (rule 1). 


-2 there is no stop-test at all (rule 3), so there are tuo (1) reasons 
to make the recursion infinite.. 


Remember that PHENARETE doesn’t know the intentions of the programmer, so 
it must detect these errors without any additional information : all that 
can be used in the further analysis are the semantic specialists and the 
pragmatic rules. So let us look at its versions : 


PROPOSITION: 


(DE FACT CN) (COND 
((LE NO) 1) 
(T (TIMES N (FACT CEUST R232200) 


AT LEAST YOUR FUNCTION SEEMS OX. 


This corrected version is actually a correct version of the 
factorial-program. The performance illustrates well the pertinance of the 
pragmatic rules, knowing that the system works completely automatically 
without asking any questions to the user and without any information about 
the supposed intention, 


One last example : 


? (DE ADDIT MN  CCCZEROP AD PD) 
CT (ADDIT EUB1 M ADDI M3) 


SURFACE IMPROVEMENTS : 
(DE ADDIT (M N) 
(COND 
CCZERUP ND M) 
(T (ADDIT CSUB1 M (ADDI 03223) 
PROPOSITION: 
(DE ADDIT M ND 


(COND 
CCZERGP ND PD 
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CCLE NON) | 
(T ADDIT £(SU31 PD (ARDI 0332) 


AT LEAST YOUR FUNCTION SE MS OX. 


The difference betueen this example and the previous one consists mainly 
in the constructed return value of the function. In the FACT example, the 
value returned was just the neutral element of the operation applied to 
the result of FACT (e.g. TIMES), in this examole a value is computed 
during the recursion, thus this newly computed value will be tne result of 
the function. 


Conclusion 


We have presented a running system which corrects incorrect student 
programs in some stereotyped vay. 


There are tuo major shortcomings ve would like to mention : 


-1- Our system relies heavily upon a (still very small)  theorem-prover, 
and - related to it - the internal representation of the abstract 
data-structures. These two modules are currently much too limited to 
apply the system to real user progams (and not only to small student 
programs). But looking at most other systems of meta-evaiuation  [10, 
12 for examplel it is one of the first systems carrying on the 
meta-evaluation not only on numeric programs but on symbolic ones, 
where no algebraic theory yet exists. 


We think we will use for the next version of the system the abstract 
List-representation proposed by Goossens [7]. 


-2- The total absence of any mean to communicate to the system the 
intentions of the programmer constitutes - as soon as one leaves more 
or less toy programs - a severe handicap. Presently we are 
investigating possibilities to encompass this shortcoming. Different 
approaches are possible and we don’t know yet which one to choose : 
either allow comments (but what should we do if there are errors in 
the comments?) or oblige the programmers to give some input/output 
examples, which would permit to use real and symbolic values (but same 
question as above). 


We are presently implementing PHENARETE as a standard VLISP [4, 9] error 
routine, L.e. as soon as during the execution of a program an error 
occurs, we trap it and apply the system to the program which caused the 
error. This will eliminate the - always existing - possibility that the 
program modifies a correct - but for tt unintelligible - program. 


A word about LISP : the only reason why we have choosen LISP is the 
isomorphism between external and internal representations, and because our 
students learn LISP as first programming language. The algorithms and 
rules used are very general and not LISP-specific. An implementation of 
PHENARETE for an algorithmic language, say Pascal for example, seems 
Straightforward : the system would even have less work in determinig the 
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symbolic values because of the typed declaration of all identifiers. 


The system is running on PDP-10, uses about 25k word memory, is 
implemented in VLISP [4,9], and is used by about 600 students in our 
university. 


À more detailed description may be found in 118]. 
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LA META-EVALUATION AU SERVICE DE LA COMPREHENSION DE PROGRAMMES 


Daniel GOOSSENS 


Le programmeur expert qui écrit, étend ou modifie en parallèle 
plusieurs programmes participant tous d’un système unique, aura besoin 
d’un assistant qui dénonce interactivement les imperfections issues de 
son incapacité à contrôler l'organisation globale de ce système. 


C'est à étudier comment atteindre ce but qu'est consacré le système 
CAN, un système de compréhension automatique de programmes LISP, 
présenté dans cette étude. CAN est implémenté en VLISP [GREUSSAY 76 
77 78 79, CHAILLOUX 78a 78b 78cl et tourne sur un PDP-10 modèle KI-10. 
Il y occupe 20K mots de 36 bits. 

CAN a la capacité de déceler dans un système dont il ne connait pas 
L’ intention des particularités telles que : 


- portions de code non utilisées 

- classes de données pour lesquelles le calcul ne termine pas 
- redondances | 

- effets de bord indésirables 


La compréhension dont CAN est capable est fondée sur un processus 
compact de méta-évaluation. La méta-évaluation permet d'effectuer en 
un seul calcul symbolique une infinité de calculs particuliers. La 
méta-évaluation utilisée par CAN représente les connaissances au sujet 
de programmes sous forme de systémes d'équations et se charge de les 
résoudre. Elle sert à analyser dans un programme le flot des données, 
dans le but d'en exhiber des particularités (calculs infinis, portions 
de code non utilisées, chemins impossibles, redondances). La 
méta-évaluation utilisée par le système CAN répond à deux types de 
problèmes posés par l'évaluation symbolique: 


- L'évatuation symbolique, dans ses réalisations actuelles [LONDON 74, . 
KING 75 76, BOYER 75b, YONEZAMA 75 76, BALZER 77, CHEATHAM 79] ne 
permet pas que soit décrit de facon symbolique autre chose que les 
valeurs associées aux identificateurs, dans un environnement. De ce 
fait, elle ne traite pas de nombreuses constructions,  fréquement 
utilisées en  LISP: variables  fonctionelles,  macro-génération 
dynamique de fonctions incomplètement spécifiées, définition de 
structures de contrôle. 


- Les résultats fournis par L’évaluateur symbolique sont souvent aussi 
peu transparents que le programme évalué symboliquement, surtout en 
ce qui concerne les programmes de traitement de Listes. Les 
représentations traditionellement utilisées par L'évaluation 
symbolique, les formules de la logique des prédicats, n'exhibent pas 
plus que les programmes qu’elles annotent, les redondances, les 
classes de données pour lesquelles le programme ne termine pas son 
calcul, les propriétés utiles de programmes. 
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La META-EVALUATION utilisée par le système CAN augmente l'évaluation 
symbolique dans ces deux directions: 


- Elle l’étend aux constructions nouvelles permises par LISP: style 
applicatif, macro-génération de programmes, affectations où 
l’identificateur n’est pas explicité, structures de contrôle 


définies par l'utilisateur, appels à l'évaluateur, programmation 
incrémentale, entrées-sorties. 


- Elle repose sur un nouveau mode de représentation des données 
symboliques: les représentations conceptuelles [YONEZANA 761. CAN 
est capable d'associer à un programme une représentation 
conceptuelle de son activité et de ses propriétés principales. 
Cette traduction en représentations conceptuelles a pour but 
d'isoler les problèmes de compréhension au sujet d'un complexe de 
programmes, sous forme d'équations à résoudre. CAN utilise alors 
des systèmes indépendants de résolution d'équations, spécialisés en 
particulier dans le traitement de listes. 


La méta-évaluation doit être utilisée et contrôlée par des systèmes 
plus larges de compréhension automatique de programmes. 


Considéré comme un système de compréhension de programmes LISP, CAN 
associe à un programme une définition sémantique, qui lui est 
équivalente, mais de laquetle il est beaucoup plus aisé d'extraire des 
propriétés importantes. Les langages de programmation, et LISP en 
particulier, déploient une immense variété de représentations de 
calculs, et permettent d'oblitérer des propriétés simples derrière des 
formules courtes, mais à la sémantique complexe. 

Pour CAN, comprendre un programme, c'est y associer sa représentation 
conceptuelle. Les représentations conceptuelles forcent L'extraction 
de ce qui est habituellement caché dans un programme: effets de bord, 
contrôle de l’évaluation, analyses de cas, structure dymamique des. 
objets manipulés par le programme. Elle peuvent ainsi isoler des 
particularités interessantes d’un programme, telles que: 


- effets de bord imprévus 

- classes de données pour lesquelles le calcul du programme ne 
termine pas 

- redondances 

- portions de code non utilisées. 


L'EVALUATION SYMBOLIQUE 


Il est possible de modifier un interprète pour qu'il tienne compte de 
la présence de valeurs abstraites dans l'environnement inote 1] d'une 
expression à évaluer. Evaluer symboliquement une expression, c'est 
l’évaluer dans un environnement insuffisamment décrit pour pouvoir 
utiliser un évaluateur classique. Evaluer symboliquement cette 
expression consiste à compléter la description de l’environnement sur 
la seule base des exigences de cette expression, et puis évaluer cette 
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Le domaine d'entrée de l’évaluateur EVAL du langage LISP est 
l’ensemble des couples «EXPRESSION , ENVIRONNEMENT» où EXPRESSION est 
une expression LISP, et où ENVIRONNEMENT donne accès à une liste de 
couples <IDENTIFICATEUR , VALEUR». 


Le domaine d'entrée du méta-évaluateur est l’ensemble des couples 
<a,h> où a et b sont respectivement une expression et un environnement 
méta-décrits. 

L'évaluateur symbolique admet que VALEUR soit méta-décrit, mais 
s'attend à ce que IDENTIFICATEUR et EXPRESSION soient des données 
concrètes. | | 

L'examen du langage LISP montre qu'il est nécéssaire que  l'évaluateur 
symbolique s'attende à ce aue IDENTIFICATEUR et EXPRESSION soient 
méta-décrits. IL doit être étendu en un méta-évaluateur. 


Exemple : 


Le langage LISP autorise l'usage d'arguments fonctionnels. Comprendre 
un programme qui possède des arguments fonctionnels, c'est pouvoir 
simuler l'application sur des données d'un programme  insuffisamment 
décrit, c'est-à-dire un schéma de programmes. 


Le tangage LISP permet, par exemple, qu'en position de fonction, dans 
une expression non atomique, se trouve une autre expression à évaluer, 
censée s'évaluer en une fonction qui sera alors appliquée sur les 
arguments. 


On peut écrire en LISP des programmes qui construisent d'autres 
programmes à partir de données, et qui les utilisent. | 


L'exemple suivant, simplifié, est tiré du générateur de conditions à 
vérifier de LIGARASHI 73] programme en VLISP. 


(DE FOO (a b) 
[A [a] 
[' SUBSTITUER 
['QUOTE a] 
['QUOTE 5111) 


(DE SUBSTITUER (s L) 


[note 1] Pour l’évaluateur symbolique présenté dans ce chapitre, 
l’environnement est une liste de couples (identifieur,valeur). Le 
mode de définition de l’évaluateur symbolique laisse cependant la 
possibilité de détailler d’autres structures dans l’environnement. 
C'est ce qui est fait au chapitre 4, où l'on y introduit une pile pour 
Les fonctions d'échappement, et des tampons d'entrée et de sortie. 
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Dans un contexte créé par un appel de FOO, SUBSTITUER remplace dans la 
Liste contenue dans Ll toutes les occurences de l'atome contenu dans s 
par la valeur de cet atome dans l'environnement courant. 

L'erreur contenue dans cet xemple est de méme nature que celle 
contenue dans le programme FILTRER, exemple du paragraphe 4.1.1, 
quoique plus complexe. Les méthodes classiques de test sur exemples 
précis ne marchent donc pas plus. 
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o bti ifl e m immi tipi am amari» s 


| Le résultat d’un appel de FOD est utilisé comme un programme et 


appliqué sur une valeur quelconque. Voici le comportement souhaité de 
l’évaluateur symbolique: | 


<(tFOD ‘a 7b) ‘u) , Q0» 


| commentaire: le travail de FOO n'est pas détaillé. 
| Une fois sa valeur retournée, les liaisons de ses 
parametres formels sont détruites. 


| <((A (a) (SUBSTITUER "m a) (QUOTE b))) "y , {> 
| commentaire: L’évaluateur symbolique doit utiliser 
| ict des connaissances sur la syntaxe des A-expressions 


et se polariser sur le cas où a est un atome litéral. 
| <(SUBSTITUER (QUOTE a) (QUOTE b) , {aszv}> 


po Re L) (SUBST (EVAL s) s 1)) (QUOTE a) (QUOTE b)) 
» FV? > 


commentaire: pour affecter les valeurs symboliques a 


| à s et b à l, l’évaluateur symbolique tient compte des 
| possibilités: | 


-Q=5 T ass, ar L 

< (SUBST ak s) s l) <(SUBST (EYAL s) s D < (SUBST d. s) s 1) 
, {s=s , S= L , S-da 

l=b}> Lb)» L-b 

; | a=v) > 

| (SUBST 's 's *b) (SUBST 'b ’s *b) (SUBST | ‘a *b) 


(SUBST x y z) substitue x à y dans z. Seule La troisième branche 


* 


correspond à l'intention initiale, qui est de substituer dans b toute 
occurence de à par V. 
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L'évaluation symbolique fournit les exemples pour lesquels l'intention 
n'est pas satisfaite: 
1. ((F00 's 'DD "y 


2. ((FOO *1 ' bo ’y) 
où s et | sont des atomes litéraux et b et v des valeurs abstraites. 
LA RESOLUTION D'EQUATIONS 


Les définitions sémantiques des fonctions de base ne décrivent plus 
les raisonnements à effectuer devant tous les types de situations 
rencontrables. Ces raisonnements sont isolés en systèmes 
indépendants. Les définitions sémantiques se contentent de décrire 
statiquement le domaine d’entrée, de sortie, la relation fonctionelle, 
ou tout autre aspect que l’on veut exhiber dans les résultats d’une 
méta-évaluation. 


La fonction META-APPLY devient un poseur d'equations. Si par exemple 
La définition sémantique d'une fonction de base FCT exhibe une 
description 4711 , envi de son domaine d'entrées, 

(META-APPLY *FCT 12 env2) 
entre autres, pose l'équation: 


«11 , envi = 412 , env2> 


C’est le système de raisonnement, indépendant du Langage de 
programmation, qui se charge de résoudre cette équation. 


exemple: | 
considérons l'exemple 1 du test LISP : 


(LAST (APPEND L M)) 


Lors de la  méta-évaluation, Lorsque la  méta-valeur de La 
sous-expression (APPEND L M) est calculée : 


«(append 1 m) , {L = 1,M = m» 
La fonction LAST y est méta-appliquée: 
(META-APPLY ’LAST ’fappend 1 m) XL = 1,M = i5 
cet appel pose tour > tour les équations: 
1- «(append 1' (cons x nil)) , env» 
= «(append 1 m) , {L = 1,M = m» 


2- «() , env» 
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= «(append 1 m), iL m» 


il 
mal 
= 

H 


les définitions sémantiques des fonctions META-CAR et META-LAST: 


ME TA-LAST: 


l~ «(append 1' (cons x nil)) , env» > «x , env» 


2- «() , env» = <f) , env» 


META-CAR: 
l- «(cons x 1') , env» > «X , env» 


2- «() , env» 5 «() , env» 


sont courtes et non redondantes. Les raisonnements communs à leur 
deux | défintions  procédurales sont isolés dans le système de 
raisonnement par résolution d’équat ions: | 


Le raisonnement commun à la  méta-évaluation des 2 formes 
(LAST (APPEND L M)) et (CAR (APPEND L MD) est la résolution de 
L'équation : 


(append a b) = (append c d) 


Pour l'exemple présent, les équations () se résolvent ainsi: 
l- (append 1' (cons x ni1)) - (append 1 m) 
donne deux solutions: | 


- m = (append m’? (cons x nii)) 
if = (append 1 m') 


I 
- 3 


"n li 


aa 1' (cons x nii)) 
2- () = (append 1 m) 


donne 1 solution: 


() 
O 


- 1 
m 


t i 


Ces trois solutions fournissent le résultat escompté. 
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UN SYSTEME DE REPRESENTATION DE SIGNIFICATIONS 


nem ——snnn— —————— P L— C Balade HÜa———D——À— :0921:421:2 A 20 00 ilum i D mm 


Un système de compréhension automatique de programmes ne doit pas se 
contenter de décrire symboliquement la succession des états de la 
machine durant l'évaluation de L'appel d'un programme. Il doit 
fournir une signification de ce programme, objet formel à partir 
duquel les applications de la compréhension (diagnostics d'erreurs, 
extraction de propriétés utiles, annotations, vérifications, 
corrections) doivent être facilitées. Les représentations utilisées 
par le méta-évaluateur défini au chapitre 4, les listes de couples 
<valeur, environnement>, sont insuffisantes pour représenter des 
programmes LISP. mE | 


Voici un système de représentation de significations de programmes. 
Ces représentations sont indépendantes d'un domaine de données (par 
exemple le domaine des listes, en LISP, sur lequel sont définies Les 
fonctions CAR CONS CDR NULL). Elles concernent le contrôle de 
L'évaluation : 


- conditionelles (IF COND AND OR SELECT) 
- itération (WHILE UNTIL MAPC MAPCAR DO) 
- appels à L’évaluateur (EVAL). 

- échappement (ESCAPE EXIT) 


- appel par nom ou par valeur (DE DF) 
(les exemples sont ceux du langage VLISP) 


Ces représentations tiennent compte également de : 


- définitions de structures de contrôle (DF et EVAL) 


- arguments fonctionnels, expressions incomplètement spécifiées 
(macro-génération dynamique de fonctions) 


- appels récursifs 


- entrées-sorties (READ PRINT) 


- programmation incrémentale (appels à des programmes non encore 
définis) 


Appliqué à une expression À et un environnement méta-décrit env, et 
s’il termine son calcul, te méta-évaluateur retourne une Liste de 
couples <valeur , environnement) tels que l’ensemble des formes 
[eny > <valeur , environnement] décrit la fonction dénotée par A. Si 
A est le corps d'un programme (A PFS . A), alors l’ensemble des formes 
[XPFS , env» > <valeur , environnement)], résultat de la 
méta-évaluation, est la définition sémantique associée à la 
A-expression. 


En appliquant le méta-évaluateur sur A dans l’environnement te plus 
global construit à partir de PFS, on peut obtenir une définition de La 
A-expression, à laquelle le méta-évaluateur peut se référer lorsqu'il 
a à comprendre une expression qui comporte un appel de cette 
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A-expression. Si une telle definition a été obtenue, le 
méta-évaluateur peut évaluer simplement une application de la 
A-expression sur des arguments concrets, toujours en se référant à la 
définition sémantique. 
exemple: 
a partir de la A-expression: 

(A CL M) (LAST (APPEND L M))) (1) 
le méta-évaluateur obtient: 

«71 (append m (cons x nil)) , env» > «X , env» 

«(append 1 (cons x nil)) () , env» > «x , env» 


«() () , env» > «() , env» 


Ceci est un programme au' méme titre que (l. Le méta-évaluateur peut 
Simplement évaluer les appels : 


(0 ’Ca bo) (de) =e 
(D "(Cabo O) = C 
(0 'O '(a b)). = b 
0 'O 'O) = () 


L'examen de cas concrets conduit à un concept de point de rupture qui 
permet de représenter de fagon uniforme des constructions aussi 
diverses que: 


- appels à l'évaluateur (fonction LISP EVAL) 


- définition de structures de contrôle (à l'aide des fonctions LISP DF 
et EVAL) 


- arguments fonctionels, schémas de programmes 
- programmes à appel par valeur ou par nom (fonctions LISP DE et DF) 
- définitions récursives 


- processus interactifs, non-terminants, à base d'entrées-sorties 


- programmation  incrémentale. Des programmes  incomplets, faisant 
appel à d'autres programmes non encore définis, peuvent toutefois 
être compréhensibles. 
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Exemple : 
Voici la définition sémantique de (l'application de) EVAL: 
«(EVAL a) , {Lisyvi}> 
2 (point-de-rupture (2) 
<a , tLi=vi}> 


<a’ , (Li-vi')» >» «a! , {Li=vi"}>) 


La forme (point-de-rupture exp . regles) indique que exp est une 
expression à méta-évaluer. regles est une continuation. 


Exemple : 
Les deux définitions : 
(DE F001 OO X) 
(DF F002 (L) (EVAL (CAR L))) 
sont presque équivalentes. C’est à dire que les appels : 


(FOOT E) 
(F002 E) 


où E est une expression LISP, fournissent la même valeur, par 
exemple : 


(FDO1 (CAR '(a b c))) a 
(F002 (CAR "(ab c))) = a 


Il 


5 


à l'exception d'une classe de cas, dont les appels : 


(FOOL (CAR L)) 
(F002 (CAR L?) 


sont un exemple. 
Si L = labo), 


(F001 (CAR L)) = a 
(F002 (CAR L)) = (CAR L) 


F001 et F002 reçoivent respectivement tes définitions (atome 
point-de-rupture est abbrévié à PR): 


<(F001 EXP) , env» 
> (PR «EXP , env» 
«X , env'» 
> (PR «(LITER 'X ’x) , env?» 
«anc-val , env''» . 
> (PR <(DELIER X anc-val) , env''> 
env!!! = «x , env'!!>))) 
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qui, par connaissance de LIER et DELIER, se simplifie en: 


<(F001 EXP) , {L=anc-val}> 
> (PR «EXP , {L=anc-val}> 
«X , {L=v}> > <x , {lsanc-vai}>) 


et: 
«(F002 EXP . Y) , env» 
> (PR «(GL IER "L ' (EXP . Y) , env» 
«anc-val , eny'’> 
> (PH «EXP , env'> 
«X , env!'» 
> (PR «(DELIER L anc-val) , env''> 
env''' 5 «x , env!''»))) 


qui se simplifie en: 


«(F002 EXP . Y) , iL=anc~val}> 
> (PR «EXP , {L=(EXP . Y)}> 
<x , tL=u}> > <x , {L=anc-val}>) 


La différence entre F001 et F002 apparait à la forme (PR «EXP , env». 
Pour F001, EXP est évalué dans l’environnement de départ. Pour F002, 
l’environnement contient la Liaison supplémentaire L=(EXP . Y. 

Ces deux définitions exhibent à la fois les points communs de F001 et 
F002 (L'évaluation de leur premier argument) et leurs différences 


(pour F002, cette évaluation se fait aprés la Liaison du paramètre L). 
Exemple : 
CAN transforme le programme : 


(DE FOO © 
(F CREAD)) 
(F00) > 


où F est un programme quelconque, en : 


<(FOD) , env» | 
> (PR <(READ) , env> 
«v , env'» = (PR «(F v) , env'> 
«v! , env''> 
> (PR <(FOD) , env''> 
yi? > 4!110)) 


où V, v' et v'' sont des variables dont le domaine est LV ensemble des 
éléments LISP. | | 


LE CALCUL CONCEPTUEL 


Le calcul conceptuel permet de représenter sous Le même statut les 
définitions sémantiques des unités syntaxiques de base, dont se sert 
le méta-évaluateur, d'un langage de programmation. 
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La méta-évaluation, appliquée à ces unités syntaxiques: 


- manipule plusieurs contextes, 
- compare des données méta-décrites (résolution d’équations). 


Ces deux fonctions sont construites à priori dans L’ interprète du 
calcul conceptuel et n'ont pas besoin d’être représentés dans la 
syntaxe externe. 


Ecrire un programme où un schéma de programmes en calcul conceptuel 
permet de le tester sur des données méta-décrites, sans qu'il soit 
nécéssaire de modifier le programme. Le calcul conceptuel permet la 
méta-progremmat ion. 


exemple: 

Voici un concept qui définit La fonction LAST. LAST évalue son 
argument, s’attend à ce que la valeur soit une Liste, retourne © si. 
elle est vide, et son dernier élément sinon. | 


<(LAST L) , env> 
> (point-de-rupture 
<L , env» 
«O , env'» = <O , env!» 
. «(append 1 (cons x nil)) , env'» 
| 2 «X , env'>) 


L'argument L de LAST peut être une expression quelconque. Le terme 
conceptuel <L , env», premier argument du point de rupture, fait 
référence aux définitions conceptuelles présentes, s’il y en a. 
évaluer une forme (LAST expression) en calcul conceptuel, c’est donc 
d’abord évaluer expression, puis comparer les résultats obtenus avec 
chacun des termes conceptuels gauche des concepts du point de rupture: 
<Q , env'» et «(append 1 (cons x nil)) , env'>. Chaque concept 
fournit une valeur et un environnement résultant de l'évaluation de 
L'expression. 


La régle de composition est la principale régle de simplification du 
calcul conceptuel. étant donnés deux concepts [tl > t2] et [t3 > t4l, 
où tl, t2, t3 et t4 sont des termes conceptuels, elle transforme la 
composition: 

[tl > t2lolt3 > t4] 


en un ensemble de concepts de la forme: 
[E >) F] 


Si un concept est interprété comme une procédure à invocation par 
résolution d'équationinote 1], alors le point de rupture peut être 
interprété comme: 


(point-de-rupture appel-de-procédure . continuation) 


La règle d’équilibration relie les concepts entre eux. 


http://www.artinfo-musinfo.org Rapport ATP 4273, octobre 1980, page 82 / 124 


-81- 
La règle du cercle vicieux : 


- Du point de vue de la méta-évaluation, la règle du cercle-vicieux 
permet d'arrêter des calculs récursifs sur des données méta-décrites 
Lorsqu'il est certain qu'aucune nouvelle information ne peut être 
obtenue. 


- Du point de vue de ta compréhension de programmes et de la 
construction de définitions à partir de programmes, ia régle du 
cercle-vicieux permet de ne pas se contenter d’arrêter La 
méta-évaluation à chaque appel récursif, et de poursuivre lorsque 
L'appel récursif n'est pas équivalent à l'appel d'origine. 


La règle d'induction constructrice est un rouage indispensable de la 
compréhension de programmes. Le système CAN obtient à partir de 
définitions récursives ou itératives des définitions conceptuelles 
dont il se sert pour effectuer des simplifications impossibles par 
simples pliages et dépliages des définitions récursives. 


L'évaluation 


Le calcul conceptuel permet d'évaluer un terme conceptuel de base dans 
un contexte formé d'un ensemble de concepts, de la méme maniére qu'il 
est possible, en LISP, d'évaluer une expression dans un contexte de 
définitions de fonctions. 


Evaluer un terme de base t (sans variable) en calcul conceptuel, c'est 
appliquer la règle d’équilibration sur le concept: 


[t = (PR t 
t' 2 t’)] 


où le concept [t' > t’] représente le fonction identité partout 
définie. 


L'évaluation symbolique 


Une évaluation intermédiaire entre cette | évaluation et La 
méta-évaluation, l'évaluation symbolique, admet que le terme à évaluer 
soit un terme conceptuel quelconque. Ce terme est une donnée 
symbolique, ou méta-décrite. C’est la représentation symbolique d'une 


classe infinie de termes conceptuels de base. 


La règle de composition doit résoudre des équations t-t' ou t et t' 
sont des termes quelconques. 


[note 11: Les «langages PLANNER [HEWITT 72] et CONNIVER 
[Mc.DERMOTT 721 3 ont introduit la notion de “pattern directed 
invocation", ou invocation par filtrage. La notion d’invocation par 
résolution d'équation en est une extension. Un exemple particulier 


d’ invocation par résolution  d'équation est Ll” invocation par 
unification en PROLOG [ROUSSEL 75]. 
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Dans le cas où les termes conceptuels ne contiennent que des variables 
d'élément, la résolution d'équations se Limite à l’unification 
robinsonienne [ROBINSON 65]. Les règles de composition et 
d’équilibration correspondent aux règles d’évaluation de clauses de 
HORN, en logique des prédicats, interprétées comme des procédures 
[VAN EMDEN 76]. La régie de résolution [ROBINSON 651, interprétée 
comme une régle d’invocation de procédure, correspond aux deux règles 
de composition et d'éguilibration. 


La méta-évaluation 


Etant donné un concept interprété comme une forme à méta-évaluer, la 
règle d’équilibration peut en général s'appliquer de plusieurs 
manières. Elle peut s'appliquer sur le concept lui-même, et sur 
chacun de ses sous-concepts. | | | | 

La méta-évaluation impose un choix simple pour l'application de la 
règle d’équilibration. Etant donnés un concept et un ensemble de 
choix d'application, la règle d'éguilibration est appliquée sur Le 
concept le plus extérieur. Si le concept n’est pas modifié par La 
règle d’équilibration, alors elle est réappliquée sur le second 
Sous-concept le plus extérieur. S'il est modifié, le processus 
recommence. Ce processus termine lorsque la régle d'éguilibration ne 
peut plus modifier le concept. 


L'Analyse de proorammes récursifs 


Les buts d'une analyse de programmes récursifs, une fois représentés 
conceptuellement, sont de : 


- décrire les classes de données pour lesquelles ie calcul ne termine 
pas, ou le programme n'est pas défini. 


- déceler les portions de code non utilisées, ou les chemins 
impossibles 


- décrire de façon statique l'activité d'un programme. 
- exhiber des inefficiences 


- reconnaître l'équivalence sémantique profonde de deux programmes. 


4 


Exemple : 


Au programme LISP qui concatène un nombre quelconque de Listes : 


(DE CONC (L) 
(COND (<NULL L) NIL) 
CCNULL (CAR L)) (CONC (CDR L))) 
(T (CONS (CAAR L) 
(CONC (CONS (CDAR L) (CDR L))))))) 
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correspondent les trois concepts : 


i- (CONC (D + [) 
2- (CONC (() . 7) > (PR (CONC 7) 
1! > 71) O 
3- (CONC ffx. y) . ID > (PR (CONC fy . 1) 
Vosdlx. 1) 


Par application de la regle d’équilibration sur chacun de ces 
concepts, 
on obtient le graphe de dépendance : 


V | 
| 2 
| 
: x | 
qui exhibe 1 comme condition d’arrêt, et montre qu’aucun arc ne relie 
3 à 1. Le chemin 3-1 est impossible. L'appel récursif de la 


troisième clause de CONC ne conduit pas directement à la condition 
d'arrét de CONC. 


~ 


La règle d* induction peut être appliquée sur 3, puis le résultat 
équilibré avec la règle 2 de CONC : 


1- (CONC (D >f) 
2- (CONC (() . 1) > (PR (CONC 7) 
1! > 1^) 8 
3- (CONC ((x1 ... xn) . 1) 
> (PR (CONC 7) 
1! > (xl... xn. 1) 


Les résultats obtenus peuvent à nouveau être compactés en utilisant 
une règle d'absorption. La règle d’absorption réunit en un seul 
concept le résultat de lL’ induction et le concept avec lequel ce 
résultat est équilibré. 


À la place de (3, on obtient : 
1- (CONC [PD 5 () 
3- (CONC [(x1 ... xn) . 1D 


> (PR (CONC 7) 
1! > (xl... xn. 1) 
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Ce dernier exemple illustre particulièrement l'avantage de la règle 
d'absorption, puisque le graphe de dépendance de CONC est réduit A: 


> [3] »[1| 
L| 


ce qui, par induction, équilibration et absorption, est compacté en : 


(CONC (fx11 ... xni) ... (xim ... xnm))) 
> {xil ... xnl ... xim ... xnm) 


ARIOMATISATION DES PRIMITIVES LISP 


Le système CAN de comnréhension automatique de programmes LISP est 
fondé sur Les règles du calcul conceptuel: composition, 
équilibration, cercle-vicieux, induction constructrice. 


Les règles du calcul conceptuel supposent une axiomatisation des 
domaines sur lesquels il est appliqué. Cette axiomatisation sert 
principalement la règle de composition, dont le rôle est de simplifier 
des expressions en concepts. Ces axiomatisations sont des systémes de 
résolution d’équations. 


Les axiomatisations requises par Le calcul conceptuel procèdent de 
principes différents de ceux des axiomatisations classiques, destinées 
à être utilisées par des mathématiciens, ou utilisées par des systèmes 
de démonstration automatique. En particulier, elles ne sont pas 
basées sur le principe d’économie, visant à réduire au maximum le 
nombre d’axiomes de base. Le calcul conceptuel demande au contraire 
d” importants systémes de déduction. Ces systèmes de déduction doivent 
minimiser les choix d'utilisation d'axiomes à chaque pas du processus 
de résolution d'équations. 


En effet, le calcul conceptuel est censé obtenir ses résultats le plus 
rapidement possible, indépendamment des moyens utilises. La 
résolution d'équations qu'utilise le calcul conceptuel ne doit pas 
s'engager dans des recherches arborescentes. Elle ne doit pas 
résoudre de probléme. Elle constitue le pouvoir déductif de la 
compréhension de programmes. Ceci distingue la résolution d'équations 
dans le système CAN des systèmes axiomatiques qui cherchent à 
atteindre leurs buts avec Le minimum de moyens. 


La représentation de La fonction APPEND comme une fonction à deux 
arguments oblige à utiliser certains axiomes comme l’associativité et 
l’élément neutre à gauche et à droite. Ces axiomes et les déductions 
qu'ils permettent peuvent être intégrés dans un mode de 
représentation. De même peuvent y être intégrées les relations entre 
les fonctions CAR CDR CONS. 


Nous utilisons les variables de séquence : 
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(APPEND L M) s'écrit (CL ?MD 


où ?L et ?M ont pour domaine l'ensemble des séquences d'éléments, y 
compris la séquence vide. 


(APPEND L NIL), par exemple, se représente (?L) 
APPEND est défini ainsi : 


(APPEND CL) €?M)) = C?L ?M) 


Cette représentation automatise l’utilisation de 
l’associativité-élément neutre de APPEND, et par l’utilisation de 
variables d'élément, distinguées par un "!", elle permet de définir 


CAR CDR CONS indépendamment les unes des autres: 


(CAR CIA ?B)) = IA 
(CDR (IA ?B)) = (?B) 
(CONS IA (?B)) = CIA ?B) 


Cette représentation uniforme des fonctions CAR CDR CONS APPEND à 
partir de filtres permet de réduire les systèmes de simplification et 
de résolution d'équations à la comparaison de filtres [GOOSSENS 78c1. 


L’utilisation de variables d’élément typées permet de définir 
conceptuellement les primitives d’un langage de programmation qui 
servent de connecteurs logiques. En LISP, par exemple, on peut 
définir: | 


CAND 1X1 ... IXn) = si (META-EVAL !X1)=NIL alors NIL 
sinon 
CAND !X2 ... 1Xn) 
(AND = T 


(OR !X1 ... IXn) = si (META-EVAL IX1)-NIL 
ators (OR !X2 ... !Xm 
sinon 
(META-EVAL !X120«!Y 
ly 
(OR) = NIL ‘ 


(IMPLIES IX IV) = si (META-EVAL !X)=NIL alors T 
sinon 
(META-EVAL !X)=!Z 
(META-EVAL !Y) 


(NOT IX) = si (META-EVAL !X)=NIL alors T 
sinon NIL 


(les variables soulignées ne peuvent être associées à la valeur LISP 
NIL. Du point de vue de la méta-évaluation, les définitions ci-dessus 
n'exhibent que le contrôle que les fonctions ont sur LV évaluation de 
leurs arguments. Les modifications qu'elles entrainent sur 
l’environnement courant ne sont pas considérées). 


Les variables d'élément typées permettent également de définir les 
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Bs 
prédicats de base (ex: ATOM, NUMBP, LISTP, STRING en LISP). 
exemple: 


(ATOM latom) = T 
(ATOM !lratom) = NIL 


ou latom et lratom sont respectivement une variable dont Le domaine 
est l'ensemble des atomes LISP et une variable dont le domaine est 
l’ensemble des éléments non atomiques. 


Ces accomodations permettent d’ étendre les résultats théoriques de 


b 


l*unification de chaines aux expressions formées à partir des 
primitives CAR CDR CONS NOT ATOM NUMBP STRING APPEND AND OR IMPLIES 
EQUAL. | | 


La définition de APPEND: 
(APPEND (?A) (?B)) = (?A ?B) 


améliore la définition classique: 


(APPEND NIL D =L 
(APPEND (CONS X Y) L) = (CONS X (APPEND Y L)) 


qui ne permet pas de simplifier Les formes : 


(APPEND L NIL) 

(EQUAL (APPEND L M) L) 

(EQUAL (APPEND L M) NIL) 

(EQUAL (APPEND L M) (APPEND L N)) 
(EQUAL (APPEND L L) (APPEND M M)) 


de même, la définition: 


(REVERSE NIL) = NIL 
(REVERSE (CONS X Y)) = (APPEND (REVERSE Y) (CONS X NIL)) 


ne permet pas de simplifier les formes : 
(REVERSE (APPEND X (CONS Y NIL))) 
(REVERSE (APPEND L MD) 
(REVERSE (REVERSE X)) 
(EQUAL (REVERSE X) X) 
elle est améliorée par cette définition, utilisée par le système CAN: 
(REVERSE (!X1 ... 1Xn)) = ClXn ... 1X1) 
qui s'écrit: 


n n 
(REVERSE (<L IX >)) = (<L IX >) 
i L i n-i+1 
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Ce genre de définition demande à accepter un nouveau type de variable 
pour construire des filtres, les notations indicées. | 


Les notations indicées 


Pour définir conceptuellement des fonctions courantes de manipulation 
de Listes comme les fonctions LISP REVERSE, MEMBER, ASSOC, NTH, 
LENGTH, il faut utiliser un nouveau type de variable dont la syntaxe 
est: 


p+ | 
<L FILTRES» 
indice 


Pour admettre ce nouveau type de variable, il faut également admettre 
des filtres numériques (p+ doit être un filtre numérique) et 
s'attendre à ce que les variables d'élément et de séquence soient 
indicées. Les filtres numériques sont exposés au paragraphe 8.2.6. 


Cette notation indicée utilisée par le système de résolution 
d'équations défini au paragraphe 8.2.5.3, se définit algébriquement 
comme le type abstrait LGUTTAG 77, BERT 79] suivant: 


type VSC (variable de séquence contrainte) 
spécification syntaxique: 


GEN : indicexfiltre-numériquexfiltre = VSC 
PREMIER : VSC > filtre 

COUPE-DROITE : VSCxfiltre-numérique > VSC 
COUPE-GAUCHE : VSCxfiltre-numérique > VSC 
ETENDRE : VSCxentier-positif = VSC 
DECALAGE-CIRCULAIRE : VSCxentier-positif = VSC 
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sémantique: 


0 
(PREMIER (GEN i n pp? = pl 
L 


Lem 


(COUPE-DROITE (GEN in p) m) = (CEN i n-m p] P 


t 


(COUPE-GAUCHE (GEN i n p) m = (GEN im p) 
(ETENDRE (GEN i n p) a) 
| axi lexCi-1) 
=(GEN i n/a p| pi. cu D 
i L 
(DECALAGE-CIRCULAIRE (GEN i n p) a) 
= si a<|p| 


*Ci-CGa-1)) 
) 


0 
((npremiers a p) 


Ji 
(GEN i n-1 (saufpremiers a p) 


i+] 
) 


(npremiers a p) 


L 


n-1 
(saufpremiers a p) 


. 


L 


NOMBRES 


~ 


Les représentations conceptuelles de Listes abstraites à l’aide de 
notations  indicées exhibent des longueurs abstraites sous la forme de 
filtres numériques, c’est-à-dire à interpréter comme des classes 
d'entiers positifs. 


Les manipulations d'entiers en LISP conduisent à des problèmes de 
compréhension qui reviennent Le plus souvent à décider de la valeur 
d’une forme: 


(relation expl ... expn) 


où relation est une des relations de base en LISP: <, >, <=, >=, =. 
et où les expi sont des expressions numériques. 


Du point de vue de la compréhension de programmes de traitement de 
Listes, il faut particulièrement s'attacher au cas où les expi sont 
des expressions sur les entiers positifs, formés à partir de 
addition et la soustraction. 

En choisissant les définitions conceptuelles: 


(PLUS XI ... Xn) = Kle ... +Xn 
(DIFFER X«Y Y) =X 

(DIFFER X X+Y+1) = 0 

(<= X X+Y) = T 

(<= X+Y+1 X) = NIL 

(>= X X+Y+1) = NIL 

(>= XY X = T 
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(< X A+Y+1) = T 
(< HAY X) = NIL 
(> X X+¥) = NIL 
(> X++ XX) = T 


Le problème auquel la résolution d'équations doit faire face se réduit 
a la résolution d’équations du type: 


alX1 + a2X2 +... + anXn + antl = b1Y1 +... + bmYm 


où les Xi et les Yi sont des variables dont le domaine est celui des 
entiers positifs et où les ai et Les bi sont des coefficients 
numériques constants, entiers et positifs. | 


Ce problème est un problème de résolution d’équations dionhantiennes 
ISTICKEL 73, HUET 781. L'algorithme  d'unification qu’utilise 
actuellement le système CAN n'est pas minimal. IL consiste en 
l’unifieur de séguences abstraites (règle 13, SUIVANT, SUIVANT 
CONDITIONE!) auquel s'ajoute une règle de simplification qui élimine 
les variables et constantes communes aux deux termes à unifier. Cet 
algorithme d’unification tient donc compte des propriétés de 
commutativité, associativité, élément neutre de +. 


LE SYSTEME CAN 


Le système CAN est un système de compréhension de programmes LISP, 
implémenté en VLISP [GREUSSAY 77, CHAILLOUX 801 sur un PDP KL-10. It 
est basé sur les processus de méta-évaluation et de construction de 
significations exposés dans cette étude. 

CAN fournit une description fonctionelle (sans effet de bord) des 
programmes qui lui sont soumis, et en simplifie la structure de 
contrôle. Cette description prend la forme d'un ensemble de concepts 
(éléments du calcul conceptuel défini au chapitre 7). Un programme 
est ainsi divisé, par l'analyse de cas opérée par méta-évaluation, en 
modules  interdépendants. CAN construit et analyse le graphe.de 
dépendance de cet ensemble de modules. 

Cette description modulaire est ensuite compactée par induction, 
autant que le permettent les notations spéciales utilisées par CAN, et 
Son pouvoir de résolution d’équations (chapitre 8). 


En analysant leur graphe de dépendance, CAN est capable d’extraire des 
programmes qui lui sont soumis : 

- des portions de code non utilisées 

- des chemins impossibles 


- des classes de données pour lesquelles le programme ne termine pas 
son calcul | 


- des redondances 


Exemples : 
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Le programme MEMLONG suivant vérifie si deux Listes ont la même 
longueur : 


(DE MEMLONG (L M) 
(COND ((ONULL L) (NULL M) 
CCNULL M) NIL) 
(T (MEMLONG (CDR L) (CDB M))))) 
réponse de CAN : 


(MEMLONG IL !M ) > 


Point-de-rupture E !L IM] 


Hon Ww ow m nm 


(NIL !5 ) 5 NIL 
( 13 NIL) > NIL 
(C (Lei 2N3+> 191 )) € (Lei PNB4> 1141 ))) 5 T 
(C (ei ?N2+> 19i D) 
( («i ?N2+>  !14i ) 247 )) > NIL 
(C («i ?N2+> !9i ) 754) 
( (ki 2N24> !14i ))) > NIL 


oun Wn nn 


Voici une définition incomplète de la fonction MEMBER : 


? (DE MEM (X L) | 

? CIF (EQUAL X (CAR L)) 
? L 

? (MEM X (CDR L)))) 
= MEM 

? 

? (CAN *MEM) 


(MEM IX IL ) > 


Point-de-rupture [ IX IL] 


yu Ww wm u i 


( NIL 
C (L<i 2N2+> !161i0 / (NIL = 1161i ))) > > NIL 


€ 1162 
( (Lei ?N3+> !16li / € 1162 # 11611 ))) D 
> € 1162 NIL) : CALCUL INFINI 


| 


1166 
C (Lei ?N4+> 1161i /( 1166 = !161i )) 1166 7168 ) D 
> ( 1166 7168 ) f 


H HW m E CI 
rs 


La classe de données pour lesquelles le calcul ne termine pas peut 
être décrite par : "les cas où X n’est pas un élément de la Liste L" 
mais cette description exclut le cas particulier, que CAN décèle, ou X 
a La valeur NIL. Dans ce cas, le calcul termine aprés que MEMBER ait 
parcouru toute la liste. 
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POUVOIR REPRESENTATIF 


CAN utilise les résultats de la méta-évaluation d’un programme pour en 


construtre une définition. 

Pour mettre la méta-évaluation au service de la comprehension de 
programmes, nous avons dû généraliser les notions déjà connues 
d'évaluation symbolique, ou exécution symbolique. Cette 
généralisation a ainsi permis de tenir compte des fonctions LISP EVAL, 
SET et DF permettant un style de programmation particulièrement riche, 
puisque l'utilisateur peut définir et utiliser ses propres structures 
de contróle, et écrire des programmes qui construisent et utilisent 
d’autres programmes. | 


Nous avons, par Le calcul conceptuel, défini une hase de 
représentation équivalente aux clauses de HORN  IKOWALSKI 731, 
fondement du langage PROLOG [ROUSSEL 751, mais ouverte vers les 
extensions nécessaires à la compréhension de programmes : 


- notations spécialisées évitant l'emploi de règles de simplification 
fréquemment utilisées 


- définitions récursives compactables par induction et utilisables 
comme règles de simplification 


Ces extensions nous ont permis d'appliquer le calcul conceptuel, dans 
le cadre de CAN, à la compréhension de programmes LISP. CAN est ainsi 
capable d'associer à un programme LISP une définition du calcul 
conceptuel, puis, si elle comporte des appels récursifs, de la 
compacter, c’est à dire de la débarasser de ses appels récursifs pour 
la rendre utilisable en tant que régle de simplification. 


Exemple : 


A partir de l’axiomatisation des fonctions CAR CDR CONS APPEND NULL 


(CAR (CONS X Y)) 
(CDR (CONS X Y)) = 


il 


X | 
Y 

(NULL ©) = T 

(NULL (CONS X Y)) = NIL 


(APPEND O L) = O 
(APPEND (CONS X Y) L) = (CONS X CAPPEND Y L)) 


et des règles d'inférence du calcul conceptuel, CAN peut, directement, 
prouver les théorèmes : | 


CAPPEND X (APPEND X X)) = (APPEND (APPEND X X) X) 
[CAPPEND X X) = (APPEND Y 1 => X = Y 


mais aussi simplifier les expressions : 
(APPEND X (APPEND Y Z)) = (APPEND (APPEND X W) Z) 


en Y = W 
(APPEND L M) = (APPEND L ND 
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dem 


en M = N 
(APPEND L L) = (APPEND M M) 
enL=M 


POUVOIR DEDUCTIE 


Le calcul conceptuel sans notations spécialisées (variables de 
séquence, notations indicées) offre un pouvoir renrésentatif 
équivalent à LISP. Cependant, il faut introduire des notations 
spécialisées pour développer le pouvoir déductif. 

Le pouvoir déductif de CAN prend la forme de systèmes de résolution 
d’équations qui tiennent compte de la présente des notations 
spécialisées. C'est l'extension par ajout de notations spécialisées 
et de systèmes de résolution d'équations qui différencie CAN des 
systèmes de vérification et de compréhension de programmes fondés sur 
la logique des prédicats. 

Cette voie est à rapprocher des tentatives de remplacement, dans un 
démonstrateur de théorèmes, d'axiomes fréquement utilisés (comme les 
propriétés d'associativité et de commutativité) par des procédures 
d’unification spécialisées [PLOTKIN 72, STICKEL 75, SIEKMANN 751. 
Nous avons contribué à ces tentatives par l'ajout de notations 
spécialisées qui tiennent compte des propriétés particulières des 
fonctions LISP REVERSE, MEMBER, ASSOC, NTH, LENGTH, LAST. CAN est 
également capable, à partir d’une définition LISP, d’en dériver une 
description à base de ces notations spécialisées et donc d’utiliser 
son pouvotr déductif pour en comprendre les utilisations. 


CAN peut être vu dans son état actuel, comme une première tentative 
d’adjoindre à tout système à trés longue durée de vie, une composante 
d'auto-compréhension nécessaire pour doter ce système d’une large 
capacité d’auto-maintenance. 

Ceci peut donner à penser que l'action ponctuelle et dominante du 
programmeur actuel sur un système à construire ou à améliorer, fera 
place à trés long terme, à une interaction programmeur-systéme, où. 
l’initiative du système pour les décisions concernant sa conception 
sera de plus en plus importante. 
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Resumé : 


Nous présentons les algorithmes de base permettant la réalisation 
de systèmes visuels d’entrées-sorties en multi-fenétres. Ces 
systèmes sont interactifs et doivent permettrent à teur 
utilisateur de reconfigurer à tout instant son dispositif 
multi-fenétres de façon continue. Sous un tel système, l'écran 
de visualisation doit apparaître comme un plan de travail virtuel 
composé de documents multiples créables et déplacables à volonté. 
Les algorithmes présentés visent à rendre, lors des déplacements 
de fenêtres, les transitions écran-écran les plus continues 
possible visuellement. Ces algorithmes ont permis, sur PDP11, la 
mise en place d’un tel système: WIN. 


MOTS-CLES: 


graphique, fenêtres, queue de priorité, bureautique, menus, 
éditeurs temps-réel,  display-vecteurs, MISA, représentations 
multiples. 


L'adjonction à la vision d'un bord arbitraire 
souligne le contraste entre la limitation de 
la perception humaine et l'infinité de Dieu. 
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1. INTRODUCTION 


Nous avons construit, pour le système VLISP, un système de visualisation par 
fenêtres, déployables et déplacables dynamiquement, tant par l'utilisateur en 


mode interactif que par programme, sous la forme d'appels de fonctions VLISP 


spécialisées. 


Ce systéme de fenétrage dynamique, WIN, est illustré dans ce qui suit par un 


bref scénario. 


modes I 


trace? 
eval? 


mide RANA me 2 LL 


MULT I -CHTNDOUW: TPPEPPPEEPET PNR Vincennes-Ircam....... May 1980 


trace? | : j 
eval? , " 


MULTI-UINDOU: 
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x » 
(= x Ù) y 
(foo (l+ x) 


ee 


tes ee 


DOWN: 


* & e * » + ena 


) 
b) y 
(foo (1+ x) 
)) 


| Vitsp-code _ 


de too (x y) 
Cif (2 x DD y 
(foo p 


e — — M — A den — — — que "à — me MM de Mu c P m 


Mutt t—-wtradoy ung | 


Dri; "2-782429 
O exec 
UP : +... 


DOWN: sr: 


MULTI-WINOQOW: .....-...--.. S... inmannaa lAAAR ——— Hu r4 
U rene erro eevee seen e Hincennes-[rcam...... Ha 1380 i 


T 
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de foo ix y 

(if (= x 0) y 

x (foo il+ x) 
33) 


M aa. Mà A a ut V a e A — aa — P a PR a 


(g 2Kde g (n) 
(if (= n 0) 1 


Ok n 
(a (1- n))))) 


Yincennes-Í[rCaM....... ra 


«e 9»0 09 9 9 9,9 * à 0 x € à * « «e nue v»? *.- 


(= x 0) y 
(foo (l+ x) 
y))) 


—  — dt et cé ue — — i m umb MEA MA a m amm dile A 


iem ee 
MULTI-UINDOM: .... rtt VEPPEEP Yincennes-ircam....... May 1980  ! 


MULTT-WINOON: 


MULTI-WINDON: 
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NL UU 
2. OEFINITIGNS 


L'écran du terminal comporte AMAX Lignes et YMAX colonnes. 


4 YHAX 


XNAX 


La position courante du curseur est décrite par Le couple de coordonnées: «XC, vC», 
xc désignant le rang de la ligne courante, ye désignant le rang de la colonne 
courante. e : 


La procédure: 
tyo(caractére) 


imprime le caractère sur la position courante du curseur, et avance le curseur d’une 
colonne. On notera que dans nos algorithmes, l'écran ne sera pas représenté 
globalement en mémoire. 


Certains caractères, dits d'échappement, n'apparaitront pas visiblement, mais 
induiront une modification globale de l’écran, ainsi: 


tyo (home) 

rangera le curseur dans le coin supérieur gauche de l’écran, de même que: 
tyo(cleos) 

effacera l'écran à partir de la position courante du curseur. 


La procédure: 
poscur (xc, yc) 


placera le curseur dans la position correspondant aux valeurs des variables xe, yc. 
L’ensemble des fenêtres apparaissant sur l’écran sera organisé comme une Liste à 
chaînage bi-directionnel représentant une queue de priorité, chaque élément de La 


queue étant constitué des champs suivants: 


adresse de la fenétre immédiatement plus prioritaire. 


suiv : 

prec : adresse de la fenétre immédiatement moins prioritaire. 
numf : numéro de la fenétre. 

xf : x-coordonnée coin supérieur gauche de la fenétre. 
yf : y-coordonnée coin supérieur gauche de la fenêtre. 
ndisjpp : adresse de fenétre plus prioritaire non-dis jointe. 
xcf : x-coordonnée curseur privé de la fenêtre. 

ycf : y-coordonnés curseur privé de la fenêtre. 

nl : nombre de lignes de la fenétre. 

nc : nombre de colonnes de la fenêtre. 

contf : adresse de la chaîne-contenu de la fenêtre. 
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3. QUEUE Ce FAIORITE 


La Liste bi-directionnelle des fenêtres comporte une fenêire-butée servant de tête de 
liste, d'edresse nremísn qui ne comportera qu'un unique champ, le champ Suivant. La 
fenêtre premfen sera toujours ia moins prioritaire. 


La derniére fenêtre de la liste sera toujours la fenêtre la plus récemment cr 
déplacée, son adresse sera repérée par la variable fccur. Le champ suivant d 
fenêtre contiendra le marqueur de fin de liste esq. 


Dans ce qui suit on dira qu’une fenêtre récente est plus prioritaire qu'une ancienne. 


(D 


Pour modifier cet ordre si on déplace une fenêtre quelconque d'adresse adf, 
pour la placer en position de priorité maximum, on utilisera la procédure: 


Remettre-en-Téte: 
si adf s fcour alors 
suiv(prec(adf)) e suiv(adf) ; 
prec(suiv(adf)) e prec(adf) ; 
suiv(fcour) e adf y suivladf) e eog ; 
prec(adf) e fcour 3 fcour e adf 
fsi 


3. VISUALISATION DES CONTENUS DE FENETRES 


Pour afficher isolément sur l'écran une fenêtre d'adresse adf, on utilisera la 
procédure suivante: 


Ait icher-Fenétre: 
xc e xf(adf) ; yc e yfCadf) ; adr e contf(adf) ; 
répéter ni(Cadf) fois 
poscur(xc, yc) : 
répéter nc(adf) fois 
tyo(mfadrl) ; adr e adr +1 
Frépéter 
xc e xc + 1 
Frépéier 


Une premiére méthode, trés grossiére, d'affichage de toutes les fenêtres de la queue 
serait (accompagnant chaque déplacement relatif du curseur et de la fenêtre qui lui 
est temporairement attachée: monter, descendre, avancer, reculer): 


fAfficher-Toutes-les-Fenêtres: 
xc el 3 yo e 1 ; tyo(home)? ; tyo(cleos) ; 
adf e suiv(premfen) ; 
tant-que adf s eoq faire 
Afficher-Fenétre ; 
adf e suiv (adf) 
ftant-que 


On notera qu’en cas de fenêtres non-disjointes, les caractères des fenêtres les plus 
récentes masqueront les caractères des fenêtres plus anciennes. 


On obtient ainsi un premier procédé de multi-fenêtragé mobile. 
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a) 


La méthode Afficher-Toutes-les-Fenêtres provoque ces transitions écran-écran tro 
brutales, demeure trés inefficiente, en nécessitant la réécriture de tout V’ écran 
chaque transition, se prête enfin difficilement au tracé d’un cadre de fenêtre si ! 
définition de l’écran en permet la visualisation. 


oS 


t9 


Ré-examinons à nouveau le probléme du déplacement progressif d'une fenêtre. Prenons, 
à titre d'exemple, une configuration d'écran à 2 fenêtres non-dis jointes: 


La remontée de fidoit provoquer l'apparition des zones: 
B' appartenant à la fenétre B 
C' appartenant au fond C 


Ceci suggére alors de traduire l'action demandée par la commande de curseur haut sous 
la forme de la séquence d'actions 


1) réécrire A une ligne plus haut 


2) pour chacune des positions de la zone pointillée libérée par le déplacement 
de A, rechercher quelle est la fenêtre F la plus prioritaire des fenêtres moins 
prioritaires que fi à qui appartient la position (elle sera nécessairement 
visible) et écrire le caractère correspondant de F. Si La position 
n'appartient à aucune fenêtre, écrire un espace. 
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En systématisant cette idée, on obtient alors les 4 cas suivants à considérer: 


uP POSITIONS DEMASQUEES 


x-coor : xf + nl - 1 


OT i y-coor : de yf à vf + nc -1 


A ttr e s rn RAT e 


POSITIONS DEMASQUEES 


—Hr x-coor : xf 


y-coor : de yf à vf + nc - 1 


POSITIONS DEMASQUEES 


RAT 

—$ x-coor : de xf à xf + nl - 1 
y-coor : yf 

LEFT . POSITIONS DEMASQUEES 

— 


xcoor : de xf à xf + nl - 1 
ycoor : yf + nc - 1 


~ 


xf, yf, nl, ne étant les valeurs des champs correspondants de la fenêtre déplacée. 
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Nous obtenons, à la suite de cette analyse par cas, les algorithmes suivants: 


Rechercher à quelle fenêtre moins prioritaire que FCOUR appartient la position de 
coordonnées <xc,yc> et ramener dans adf l'adresse de la fenêtre qui posséde cette 


position. Si la position visible n'appartient à aucune fenêtre, ramener la valeur de 
premfen (la butée) dans adf. 


Fenditre-ca-Pesiticn: 

adf + prec(fcour) ; 

tent-que adf s premfen faire 
Si xc c [xfCadf), xf(adf) + nlCadf) - 11 alors 
sins? yc € lyf(adf), yf(adf) + neCedf) - 1] alors 
sinon exit 
Fsi 
adf e precladf) 

Ftant-que 


On balaye donc la liste des fenêtres, à partir de la précédente de fcour, en ordre de 
priorité décroissante. 


Etant donné une fenêtre d'adresse adf qui posséde la position d'écran de coordonnées 
<XC,YC>, ramener dans caractère le caractère correspondant de la fenêtre (on 
transforme les coordonnées-écran absolues <xe,ye> en coordonnées relatives à la 
fenêtre). Si cette position n'appartient à aucune fenêtre, placer le caractère 
"espace" dans caractère. 


Carectére-de-Positicn: 
Si adf = premfen alors caractère e " " 
sinon 
rxc e xc - xfladf); ryc e yc e yf(adf) ; 


caractère e micontf(adf) + nc(adf) x rxc + ryc] 
Fsi 


Imprimer le caractère correspondant à la position <xc,yc> de la plus prioritaire des 
fenétres moins prioritaires que fcour. 


Imprimer-Caractere: 
Fen&tre-de-Position ; 
Caractére-de-Position 
tyo(caractére) ; 


we 
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On obtient enfin les algorithmes de mouvement ascendant, descendant, gauche et droite 
de la fenêtre courante, d'adresse fesur: 


ionter: 

adf e fcour s xfladf) e xf(adf) - 1; 

Afficher-Fenétre ; 

xc e xf(adf) + nl(adf) ; 

yc + yf(adf) ; 

poscur(xc, yc) 3 

répéter nc(adf) fois 
Imprimer-Caractére ; 
yc e ya + 1 

frépéter 


Descendre: 

adf e fcour s; xf(adf) e xf(adf) + 1 ; 

Afficher-Fenêtre ; 

xc e xf(adf) - 1 ; 

yc e yfladf) y 

poscur(xc, yo) ; 

répéter nc(adf) fois 
Imprimer-Caractère : 
yc e yc + 1 

frépéter 


fivancer: 
adf e fcour 3 yf(adf) e yfladf) + 1 ; 
Afficher-Fenétre ; 
yc e yf(adf) - 1 ; 
xc e xf(adf) y 
répéter nl(adf) fois 
poscur(xc, yo) ; 
Imprimer-Caractère : 
xc exo +1 
frépéter 


Reculer: | .. | 
adf e fcour ; yf(adf) e yf(adf) - 1 ; 
Afficher-Fenétre : 
yc e yfladf) + nc(adf) ; 
xc e xf(adf) ; 
répéter nl(adf) fois 
poscur(xc, yo) ; 
Imprimer-Caractére ; 
xc + xc + 1 
frépéter 


Sur ces bases, de nombreuses améliorations sont possibtes, essentiellement 
dépendantes de la place mémoire disponible, parmi lesquelles: 


- introduire un ou plusieurs champs supplémentaires dans Les fenêtres 
permettant de trier les fenétres par ordre de xf, yf, xf4nl, yf+ne croissants, 
pour accélérer la recherche. 


- si les caractères sont stockés sur 7 bits, utiliser Le 8éme bit comme bit de 


marquage, placé par La fenêtre à qui appartient la position absolue 
correspondant à ce caractère. 


- réorganiser le système sous forme d’un système de passage de messages: Les 
couples <fenétre, position> seront considérés comme des acteurs recevants et 
s’envoyant mutuellement des messages d'occupation et de Libération de 


positions. 
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5. BORDS 


Le tracé efficace de bords de fenêtres, sous forme de vecteurs, qui devront être 
également déplacables et - masguables, sera relativement plus délicat. Nous 
examinerons une série de solutions d'efficacité croissante et de simplicité 
décroissante. 


Naturellement ces bords, pour être mis en jeu, nécessitent un écran convenable: de 
type display-vecteur ou bit-map. Les algorithmes qui suivent concerneront un écran 
de type display-vecteur, tel que ie VT11 de la compagnie DEC. 


L'écran est encore une matrice de positions adressables en coordonnées x-y, que nous 
supposerons disposer de 1024 Lignes et 1024 colonnes. 


Le contrôleur de cet écran doit être conçu comme un processeur séparé à part entiére, 
mettant en jeu les instructions (d-v-instructions) suivantes: 


{POINT x y} 


Se positionner sur l'écran à la position «x, y». 


(LONGV ax ay} 


Tracer sur l'écran, à partir de la position courante, un vecteur de longueur définie 
par l'incrément horizontal ax et par l'incrément vertical ay. 


Un bit positionné dans l'incrément a décidera si le tracé de vecteur a lieu dans la 
direction | horizontale décroissante: minusx ou dans la direction horizontale 
décroissante:  minusy. 


{DRET} 


Re-exécuter tout le d-v-programme à partir de sa premiére instruction. On nommera 
rafraîchissement de l'écran une re-exécution du d-v-programme. 
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Comment afficher les bords d'une fenêtre de la liste des fenétres ? 


Si la fenétre était totalement visible, nous aurions à tracer les 4 vecteurs orientés 
or thogonaux A 


D 


Si, en revanche, la fenétre n'était que partiellement visible, ce serait l'effet de 


fenêtres plus prioritaires partageant des positions de sa surface. Nous pourrions, à 
titre d'exemple, avoir les 5 vecteurs suivants: 


Li... um Ov “pdt o us. o = ee A3 


Une premiére procédure de génération du d-v-programme correspondant sera alors: 


Pour chacun des bords 1, 2, 3 et 4, construire à partir de la premiére position 
visible «xp, yp», un vecteur de longueur égale au nombre de positions visibles 
à partir de celle-ci dans cette direction, et recommencer à partir de la 
prochaine position visible du bord. 


Comment déterminer, pour une fenétre adf, si une position de coordonnées <xR, yR> est 


ou non visible ? Cette position sera effectivement visible si elle n’appartient pas 
à une fenêtre plus prioritaire que adf. 
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On a alors l'algorithme: 


VISIBLE: 

auxADF e suivCadf) ; 

tant-que auxADF = 0 faire 
Si xR 4 [xf(auxADP), xf CauxADF) + nllauxADF) - 1 
sinsi yR € [LyfCauxADF), yf(auxADF) + nelauxADF) - 1 
sinon visible e faux ; exit 
Fsi 
auxADF e suiv(auxADF) 

Ftant-que 

visible e vrai 


Ors 


l ai 
] alors 


Comment obtenir, dans xP et yP, les coordonnées physiques de L'écran-d-v 
correspondant aux coordonnées «xf, yí» de la position supérieure gauche d'une fenêtre 
d'adresse adf ? 


L'algorithme suivant mettra en jeu les constantes suivantes: 


homex: x-coordonnée de la position supérieure gauche 
du d-v-écran. 

homey: y-coordonnée de la position supérieure gauche 
du d-v-écran. 

car. largeur: largeur d'un caractère. 

car.heuteur: hauteur d’un caractère. 


POSITION-EGRD-FENEZTRE: 
xp «€ homex + car. largeur (yf(adf) - 1) ; 
yp + homey + car.hauteur x xf(adf) 


se 
© x 


On obtiendrait, à titre d'exemple, pour le bord 1 de la fenêtre adf, l’algorithme 
suivant, utilisant le booléen progremme-généré: ce dernier sera vrai lorsque la 
Longueur av d'un vecteur est en cours de construction pour un segment visible du 
bord. La procédure Construire place ses arguments à la suite des d-v-instructions du 
d-v-programme en construction. 


Position-Bord-Fenétre ; 
xR e xf(adf) ; yR e yf(adf) ; 
programme-généré e faux ; 
répéter nc(adf) fois 
Si visible afors 
si programme-généré alors 
AV + AV + car. largeur 
sinon 
Construire{POINT xp yp? ; 
AV + car. largeur ; 
programme-généré e vrai 
fsi 
sinsi programme-généré alors 
Construire {LONGV av 0) ; 
programme-généré e faux 
Fsi 
xP e xP + car. largeur ; 
yR e yR + 1 
Frépéter | 
Si programme-généré alors 
Construire{LONGV av 0} ; 
programme-généré e faux 
Fsi mE 
yR e yR - 1 
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La généralisation de cet algorithme nous donne alors l'algorithme d'affichage de bora 
d’une fenêtre d'adresse adí: 


BORD-FENETRE: 
Position-Bord-Fenétre ; 
xR e xf(adf) y yA e yftadf) ; 
programme-généré + Faux ; 
Bord(nc(adf), car. largeur, car. largeur, xP, av, 0, yR, 1) ; 
Bordínl (adf), car.hauteur, -car.hauteur, yP, 0, avaminusy, xR, 1) : 
Bord(nc(adf?, car. largeur, -car. largeur, xP, av,minusx, 0, yR, -1) ; 
Bord(nl(adf), car.hauteur, car.hauteur, yP, 0, av, xR, -1) 


qui utilisera la macro: 


BORD(nbr, iav, iBordPos, BordPos, xav, yav, Pos, iPos) 
répéter nbr fois 
Si visible alors 
Si programme-généré alors 
AV € AV + Lav 
sinon 
Construire {POINT xP yP} ; 
AV + iav 3 programme-généré e vrai 
Fsi 
sinsi programme-généré alors 
Construire{LONGV xav yav} 3 
programme-généré e faux 
Fsi 
BordPos e BordPos + iBordPos : 
Pos e Pos + ¡Pos 
si programme-généré alors 
Construire{LONGV xav yav} ; 
programme-généré e faux 
fsi 
Pos e Pos - ¡Pos 


L’algorithme d'affichage de bords de toutes les fenêtres de la liste des fenêtres 
devient alors: 


"stopper le d-v-programme d'affichage de bords" ; 
adf e fcour 3 
tant-que adf s premfen faire 
Bord-Fenétre ; 
adf e precladf) 
ftant-que 
Construire{DRET} ; 
"redémarrer le d-v-programme d'affichage de bords" 
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Cet algorithme, quoique correct, demeure relativement inefficient: une premiére 
amélioration peut consister à afficher, au fur et à mesure de leur construction, les 
{POINT x y} et les {LONGV ax ay}, afin d'obtenir un réaffichage plus continu. 


Par ailleurs, il n’est pas nécessaire de recalculer, pour toutes les positions d 
bord d’une fenêtre, si elles sont visibles dans cette fenêtre ou masquées par un 
fenêtre plus prioritaire. 


Une premiére amélioration consiste à déterminer en temps constant si La fenêtre 1 
dont on veut afficher ls bord et une autre fenêtre w2 plus prioritaire sont ou non 
dis jointes. Si elles sont effectivement disjointes, cette fenêtre disjointe 
prioritaire pourra étre  ignorée, pour toutes les positions de bord de la fenêtre 
candidate à l'affichage, dans le test de visibilité. Ce pré-test améliorera alors 
considérablement la vitesse de fabrication du d-v-programme d’affichage. 


On peut distinguer, en premiére approche, 4 cas de conditions suffisantes de 
dis jonction. 


CAS 1 
xhul) > xb(Cu2) 
CAS 2 
ydíwl) < vg(u2) 
CAS 3 
xb(w1)> < xh(w2) 
CAS 4 
yotwl) > yd(w2) 
avec xh = xf , xb = xf + nt - 1 
yg = yf, yd = yf + nc - 1 


Le pré-test de visibilité consistera à constituer, à partir de la Liste des fenêtres 
plus prioritaires, la sous-liste des fenêtres non-disjointes. L’algorithme de 


visibilité d’une position ne testera le masquage possible de cette position que pour 
ces fenétres non-disjointes. 
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Dans le cas où une fenêtre d'adresse ALF, de priorité quelconque, est disjointe de 
toutes les autres (liste des ‘fenêtres non-disjointes vide), ce qui s’applicue 
également à la fenêtre courante FCOUR, l’algorithme direct d'affichage total des 
bords sera mis en jeu dans la fabrication du d-v-programme: 


ConstruireiFOINT xp yp} ; 

xD + car. largeur « nc(adf) 3 yD e car.hauteur x nl(adf) ; 
Construire{LONGY xD 0) ; 
Construire{LONGY 0 yDaminusy} 
Construire{LONGY xD minusx 0) 
Construire{LONGV 0 vD? > 


va ep 


On notera qu'aprés l'execution d'un LONGY, la position courante sur Le d-v-écran est 
celle de l'extràmité finale du vecteur affiché par LONGY. 
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